The article that Richard referenced also had a link to the Phd dissertation where REST was originally defined:
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm ;
The definition is quite broad, and much of it abstract, so I can understand how that might lead to a variety of interpretations. However here's my summary:
- An architecture with a clear separation of concerns between client & server primarily. However one that also includes "layers" with roles for client cache, server cache, proxy services, DNS services, gateways, firewalls, and tunnels such as VPN.
- Communication must be stateless between client and server and all connectors in between. Provides for multiple requests to be processed asynchronously and in parallel without concern for the state of each or any. A good example would be an HTML page that includes perhaps dozens of references to other hypermedia content (JavaScript files, CSS files, images, audio, video) which may be requested in parallel.
- Cache constraints must be implicitly or explicitly delineated in every response; providing for improved performance and scalability.
- Uniform Interface. Resources are requested via URLs. REST relies on the author choosing a resource identifier that best fits the nature of the resource requested.
- Code on demand; supporting requests for code such as Javascript, applets, plugins, and XML style sheets.
- Metadata is in the form of name-value pairs. HTTP post and query string formats are good examples.
- Protocols are limited to what you can communicate by using URLs. That may be why REST is contrasted against WSDL and SOAP based web services.
Interestingly, there is no mention of HTTP POST, GET, DELETE, or PUT operations in the dissertation. That must be someone's later interpretation of a "Uniform Interface". But again, the abstract nature of the dissertation leads to some interpretation.
When it comes to web services, it seems that we need some way of distinguishing WSDL and SOAP based architectures which add considerable overhead and arguably much unnecessary complexity to the interface. They also require additional frameworks and developer tools in order to implement. I'm not sure if REST is the best term to distinguish between common-sense interfaces and overly engineered interfaces such as WSDL and SOAP. But we need something.
-Nathan.
________________________________
From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Sent: Friday, January 27, 2012 8:27 AM
Subject: Re: XMLSERVICE
Richard,
It's unclear to me what your definition is...
For a web service to be RESTful, the HTTP method must control the
action, and the URL must identify the business object to operate on.
Example:
GET
http://example.com/orders/12345
This would retrieve an order number 12345. The "verb" is the HTTP
method, in this case, GET -- which means to retrieve. The URL
identifies the order.
PUT
http://example.com/orders/12345
Same URL, but this time it creates/replaces the order, because the PUT
method was used.
POST
http://example.com/orders/12345
Modifies an order, because it's a POST operation
DELETE
http://example.com/orders/12345
Hopefully you get the picture. Now let's say I decided to do this using
XMLSERVICE
POST
http://example.com/cgi-bin/xmlcgi.pgm
The object being identified would be in an uploaded XML document. The
action to perform would also be in the uploaded XML document. The action
is NOT determined by the HTTP method. The object to operate on is NOT
determined by the URL. It's not RESTful.
It has nothing to do with whether the parameters are/aren't in XML.
It's the very fact that the object to operate on is _in_ a parmeter (as
opposed to the URL) and the action to take is also _in_ a parameter (as
opposed to using the HTTP method) that tells us that it is not RESTful.
I only skimmed the article you linked to, but it seems to agree with me.
You refer to "small semantics" and an in earlier post you referred to
"purists". The problem is, these "small" semantics you refer to are the
/defining/ characteristics of what RESTful is.
Saying that XMLSERVICE is RESTful except for small semantics is like
saying that I'm a woman except for small semantics. I'm very similar to
a woman! I have a head, two arms, two legs. I speak the same human
languages that women speak. I eat, sleep, breathe, drive cars, read
books, and type on a keyboard, just like a woman does. There are only a
few small differences between me and a woman, right? The problem is...
those small differences _are_ the defining characteristics. Namely, that
I'm MALE.
The same is true with XMLSERVICE. It's not RESTful, because it doesn't
use the HTTP method as a verb, or the URL as the noun, and these are the
defining characteristics of what it means to be RESTful.
midrange.com
