The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Thomas Bandholtz on Apr 08, 2008
"What makes a cool URI?
A cool URI is one which does not change.
What sorts of URI change?
URIs don't change: people change them."
Today's cool URIs are not that simple. In 2005, after a lasting debate on "the range of the HTTP dereference function" (httpRange-14), the W3C Technical Architecture Group (TAG) finally decided that "if an HTTP response code of 200 (a successful retrieval) was given, that indicated that the URI indeed was for an information resource, but with no such response, or with a different code, no such assumption could be made", as summarized by TBL in 2005. The current SWEO Note refers to a more detailed posting by Roy T. Fielding.
a) If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource;
b) If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;
c) If an "http" resource responds to a GET request with a 4xx (error) response, then the nature of the resource is unknown.
Fielding is almost a synonym for the REST architecture. However, the httpRange-14 decision has been hardly recognized in RESTful SOA, e.g. neither in Mark Bakers article on the "hypermedia constraint", nor in Anne Thomas Manes' "REST is about Resources". URIs are Uniform Resource Identifiers, a fundamental concept for REST in general. The SWEO Note solely adds "a practical guide for implementers of the RDF specification" as an exemplification.
RDF stands for Resource Description Framework, which "allows users to describe both Web documents and concepts from the real world - people, organizations, topics, things - in a computer-processable way. Publishing such descriptions on the Web creates the Semantic Web." The co-occurrence of human-readable Web documents - also called: "information resources" - and computer-processable descriptions or semantic concepts raised ambiguities about what HTTP URIs identify . Does http://www.example.com/people/alice represent Alice's nicely designed home page, or some RDF encoded metadata about Alice? Could it as well be a vCard, a FOAF record, or some HR dataset following any company-specific scheme?
Such questions are out of scope of the protocol-independent URI syntax , it's up to the HTTP protocol to provide content negotiation as a solution. HTTP clients may pass over the preferred data formats and languages along with the target URI in the request header, and the content provider should serve these settings. The SWEO Note provides a solution that implies one individual URI for each data format, plus one "generic". This allows for direct linking to a specific preference among the multiple presentations, if required, while the generic URI will redirect to one of these, according to the given "accept" settings in the HTTP request at execution time. A more detailed best practice for the Apache HTTP Server has also been published.
RESTful SOA may argue that this mainly fits for a provision of fix document files. A dynamic SOA server can easily implement this "generic" URI concept without any redirection, just by rendering the content in the requested format on demand. This view satisfies content provision, while the redirection architecture better supports linkage and reference. It also leverages resource management and governance, be it in the Semantic Web, or in RESTful SOA. And may be these two application areas are not so distinct from each other.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
No comments
Watch Thread Reply