Understanding REST

There are a lot of people talking about REST (1) yet very few actually have taken the time to read Roy Fielding's thesis about it. This blog post will attempt to explain REST in a simplified manner to convey the basics. Please do not consider this authoritative however. REST means different things to different people at this time and this blog post is based on REST as per Fielding's work.

First and foremost, REST does not equate to HTTP and XML. REST is an architectural style. Encapsulated within the REST style are several key principles governing network architecture. While the HTTP/XML confusion reigns in most articles, it is in fact possible to write an HTTP and XML interface to a resource that does not comply with the principles of REST.

REST can be simplified down to the following:

1. REST begins with the notion of a null architectural style (imagine that there is only a "thing" with no discernible detail). From this emptiness, the first constraints of REST emerge. A client-server architecture is the first emergent principle; a separation of all into two concern groups. This allows each group to evolve separately and scale across multiple domains (similar to SOA).

2. REST then adds the principle of stateless binary relationships. In section 5.1.3 of his dissertation, Fielding writes "each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server". These types of requests are also termed "idempotent". Inference? Any site using cookies or stored contexts is not compliant with REST.

3. REST does make the possibility of caching available to improve efficiency. While not violating the principles of stateless invocations, client side caches can be used to allow reuse of information.

4. Uniform interfaces and uniquely identified resources are pivotal to being RESTful. Having a uniform interface between components (such as the use of certain methods like GET, POST, PUT and DELETE in protocols like HTTP), enables implementations to be decoupled from the service interfaces. This principle is also embodied in Service Oriented Architecture, which perplexes me why so many people compare SOA to REST.

Fielding writes more about the subject in section 5.1.5 "In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state."

5. A resource is explicitly defined as "the intended conceptual target of a hypertext reference" and later in section 5.2.1.1 as "any information that can be named...". The first of these definitions seems to concretely link HTTP to REST yet there are arguments that hypertext is used here in a generic manner. In fact, later in section 5.2, it quite explicitly states "REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components". Nevertheless, the way to interact with resources is via representations of the resources, as per 5.1.5. Note that Resource is defined in W3C terms as "any thing that can have an identifier".

6. Resources are identified with a URL or URN. Note that in this case, the URL should be constrained to be free of non-uniform interfaces (such as http://www.domain.com/someOperation?operation=manipulationByURL&moreOperations=notAllowed). This style of manipulation of data elements through invocation of non-standard operations is the anti-pattern or REST. REST therefore can be contrasted to Remote Procedure Calls (RPC) which generally encapsulate the notion of invoking a procedure on a remote server.

REST is an abstraction of all these architectural elements plus a few more within a distributed hypermedia system such as the Internet. Now here is the one sentence summary:

REST-based architectures communicate primarily through the exchange of representations of the state of resources through uniformly defined interfaces.

Try saying that 5 times fast.

So is it possible to define RESTful services for SOA? Absolutely. Do you have to use XML in REST? No.

There is a lot more about REST that you should look at in detail but I think this captures the gist.

Don't believe me though - read about it here yourself. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

References:

(1) Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000

Ontology advice needed for SEO playground.

OK - I am a geek. A nerdling. Social misfits do stuff like this just to prove it can be done. Here is my current question du jour.

I am right now placing First Order Logic (FOL) binary and n-ary relationships into the associations binding for labeled relations in a test metadata facility (Registry-Repository). I am doing this because I got sick of Computational Intelligence researchers just talking about this and not actually coding and doing something to solve the problem so the Canadian cowboy instinct to code first and see where problems arise has taken over. Search technologies on the web have kind of plateaued. With no real competition, are Google and Yahoo going to keep innovating search to the point where a 3-word search term can find a needle in a haystack? I do not think so but it is not outside the realm of possibility. While researching some advanced SEO topics, I started realizing that fuzzy logic and quantum computing patterns have not yet been optimized for NL programming heuristics.

I have run into a problem that I would appreciate input on. My goal is to bind something like this (From SUMO - thanks to Adam et al for doing the hard work).

(=>
(instance ?OBJ Object)
(exists
(?TIME1 ?TIME2)
(and
(instance ?TIME1 TimePoint)
(instance ?TIME2 TimePoint)
(before ?TIME1 ?TIME2)
(forall
(?TIME)
(=>
(and
(beforeOrEqual ?TIME1 ?TIME)
(beforeOrEqual ?TIME ?TIME2))
(time ?OBJ ?TIME))))))

..to a registry-repository node instance to allow folksonomy tags to reference the upper level ontology classes that the folksonomy tag owners believe they belong to. Additionally, each instance of a folksonomy tag may have * relationships to other ontology classes or even other folksonomy tags. The latter relationships can be defined in terms of constrained relationship tags like “synonym, disjoint, etc.”.

I want to represent all upper ontologies; however some of them contain subtle nuances between their terms. Dolce, SUMO and others have defined binary relationships like transitive, intransitive, reflexive, irreflexive, symmetrical as well as some partial ontologies. The problem is that there are no namespace qualifications for these so I want to introduce that into my work. I was planning on just using the root URLs for each work however there are versions possible in some of the work.

I would like this to be in the form of (upper_ontology_identifier)+(version_or_instance)+(uuid) as a classifier followed by the term label such as “transitive”. I will probably use URIs for the UUID.

Question:

Has anyone ever come across a similar problem and if so, how did they solve it?

Thoughts and comments welcome too.