Web services are generally thought of as SOAP
over HTTP. Another approach is REST.
An alternative web services technology is Representational State Transfer (REST)
, an approach that tries to be much simpler than SOAP. The idea is that HTTP isn't just the transport for a web service, it is the web service. By this definition, the web itself is a REST system.
With REST, each resource/object exposed to the web has its own logical URL for accessing it. (The web server maps the URL to the object so that each object doesn't need its own static page or predefined URL.) The services are the HTTP verbs GET, PUT, and DELETE, for viewing, updating, and destroying the object. (There's also POST, which is a heck of a lot like PUT.)
I haven't programmed in REST (yet), but from what I've read, a REST web service for browsing and ordering products might work like this:
The HTTP request and response can contain any HTTP data. It's usually XML (MIME type
), using schemas defined by the services provider (
in this example). A service may support multiple data representations, then negotiate with the client to determine which to use for that particular client.
A common debate theme within the REST community is how the HTTP verbs (GET, PUT, POST, and DELETE) are supposed to work in a web services context. People describe their services as "I think this is RESTful," meaning that the URLs represent resources and the service implements the verbs properly/as expected. But the developers often seem uncertain of themselves, debate the tradeoffs, and sometimes disagree.
There is no formal Java API for using REST. It's so much like good ol' HTTP, perhaps you don't need a new API or library, just a servlet that performs GET, PUT, POST, and DELETE as defined in REST. (I don't think you can necessarily assume that the average Java servlet is automatically REST compatible!) There's support for REST in Apache Axis 2.0
and an article on implementing REST in Java, "The REST of the Web
For more info:
Aug 18 Update:
On advice from my commenters (see below; thanks for the comments, guys!), an HTTP GET should have no side effects (makes sense). Creating an order so that it can be returned is obviously a side effect, so GET is not appropriate. Seems like if you wanted your web site/web services to be read-only, you'd only support the GET verb.
Accordingly, I've changed the single GET command that I imagined would create and return an order to two commands: a POST to create the order, which returns the URL for the order, and then a GET to retrieve the order. Two commands instead of one seems like more work, and is definitely more round trips across the network, but apparently this is the way REST (and HTTP) works.
I'm still not clear on the difference between PUT and POST. Notice that I now POST to create an order and PUT to update it. Is this correct?
Not to get grouchy here, but REST is supposed to be simpler than SOAP. Seems like when the verbs are somewhat unclear like this, and when it takes multiple commands and round trips to perform one logical action, it takes away from the simplicity.
Aug 20 Update:
Again, thanks to my commenters for helping me understand REST better.
OK, so PUT is like a setter method (and GET is like a getter method; duh). POST is like "perform an action." This is a true service method, where the service can be anything. It's like document-style SOAP (not RPC-style), where you don't tell the receiver what to do, you just pass the receiver some data and say "process this," and the receiver figures out how to process it.
So GET, PUT, and DELETE are pretty straightforward, actions performed on the resource/object specified by the URI. POST is the miscellaneous verb, telling the resource to do whatever processing it thinks is appropriate.
Where is this stuff documented (besides trying to decipher the HTTP spec)? Seems like there ought to be a simple "REST Style" guide that explains this pretty briefly, but I haven't found one.
I appreciate both commenters' insights, but I found this suggestion a bit concerning: Use the HTTP 201 (created) response
, put the URI for the new order in the response's Location response-header field
, and put the order XML doc in the response's entity-body
. I'm kinda impressed by how creative this approach is, but again it confuses me even more as to why proponents seem to think that REST is so much simpler and easier than SOAP. You need to not only understand these HTTP verbs, but also status codes and header fields? Seems to me that any particular provider's REST services are going to need a lot of documentation, not unlike SOAP or Java or any other programming. How's this simpler?