When it comes to RESTful Web services, it's as important to understand the why as much as the how. Roy Fielding's doctoral dissertation (see Resources) -- the source of the REST acronym -- outlines two approaches to Web services: one that's service-oriented and another that's resource-oriented. Before I show you the code to implement your own RESTful resource-oriented architecture (ROA), I'll clarify the differences between these two design philosophies, and I'll discuss the two competing definitions of REST in popular usage. As your reward for taking in all the talk in the first part of this article, you'll find plenty of Grails code later on.
Scott Davis describes how Grails applications can be a resource of raw XML data that other applications can consume through RESTful service calls. This approach allows programmers to return Plain Old XML (POX) instead of coupling the service to a specific implementation of SOAP. Scott writes:
- Posted by: Ryan Taylor
- Posted on: September 23 2008 09:40 EDT
The author has an aside of Put vs. Post. he says:
Given the fact that all major browsers lack support for the PUT method when submitting HTML form data (they support only GET and POST), it's difficult to determine what the wisdom of crowds has to say about which method should be used in which case.Its pretty simple. PUT is idempotent, POST is not. If you can express all the interaction with your service through idempotent methods, then your service is much more scalable and has a lot less bookkeeping to worry about (i.e. duplicate messages in an unreliable network). Also, to be "browser compliant" there are a few different ways to tunnel PUT and DELETE. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
Well ,in my view we should not think REST in the browser perspective ,HTTP is just one implementation of REST style . If we look REST in general PUT and POST has real difference when it come to the implementation. Deepal http://blogs.deepal.org
Damn, what a sad day, Spring Source folks insults the open source community with their new policy, poor Grails. Grails should change their middleware architecture for other framework. Spring is KAPUT!.
Reading the article I wonder how is it people can confuse terms and ideas so easily when the term is so plain clear! First of all, I see no place in Fielding’s thesis mentioning Web Services in SOAP sense! He actually defines what a component is, based on Parnas, and how the component provides some services. That is all. All mentions to services are related to that definition. No SOAP and no such things as Service-oriented and resource-oriented Web Services (sorry, that makes no sense at all). A web service is a web service: a service offered through web. The standard may force you use SOAP for commercial reasons, agree, but that doesn’t mean a web service that does not use SOAP is not a service! Actually, a web service is a service implemented using web semantics. Period. First, please read Fielding’s text. Do not confuse SOAP with RPC, and do not confuse services with RPC. They are not the same thing. SOAP is actually RESTfull!!! Please read sections 6.5.2 (HTTP is not RPC ) and 6.5.3 (HTTP is not a Transport Protocol). There Fielding clearly mentions a way of creating network based APIs, getting rid of language and RPC coupling. William Martinez Pomares Architect's Thoughts