You must not have read the comments, where I clarify my post to say:

“This is not what *I* define as REST, HTTP+POX, and SOAP, or believe the “correct” definitions are.

However, in my opinion, based on talking up eBay web services at many places for the past 2.5 years, if you went to a couple of web conferences and polled the attendees on their definitions of the terms, the results would be what I describe above.”

Things have changed a lot around REST in the past 4 years, so I don’t think I would make those statements today, but I still contend that was common opinion in 2006.

REST assumes a data-centric view of applications and assumes that PUT (create), POST (update), and DELETE (delete) can be used to cover all of the transformations a data resource might undergo. GET is, of course, used to retrieve data resources.

Adam is probably correct in saying that most sites purporting to be RESTful use only GET, and that they make excessive use of HTTP query parameters. Personally, I would call them RESTful query applications, not full REST applications.

Perhaps I’m oversimplifying, but the only query parameters in my REST applications are used to identify whether the response should be the default XML, or XHTML for display formatting. The URL, itself, identifies the data resource — and the HTTP verb identifies what is to be done with/to that resource. PUT and POST carry their data in XML format in the post data stream. My Web user interfaces are AJAX (built with the GWT) so there is no difficulty working with XML.

That said, perhaps the lack of PUT/DELETE is caused by the lack of browser support? (And they’ve been kind of the hidden stepchildren of the HTTP verbs…) I definitely do agree with your point and want to apologize for jumping on you. It just seemed like you were stating your definition for “what is REST” as opposed to “how is REST implemented”.

There are multiple sites that describe REST using POST, PUT, and DELETE, but I find very few (if any) major sites that deploy “REST Web services” using POST, PUT, and DELETE. Can you name some?

Leonard listed S3 and GData. Those are relatively new and GData is based on Atom, so it’s not as if Google made that up on their own.

Also, eBay web services are *far* from read only! We have allowed read and write operations since 2001! Over 50% of eBay item listings come through web services.

A quick google of HTTP REST nets me quite a few pages that involve the words POST, PUT and DELETE, so I am inclined to think that the people writing about REST web APIs disagree with you :)

And again, I think alot of the confusion is that eBay web services by nature are read only, making it seem like all “REST” interfaces only use GET and huge fat query strings. That said, I must argue that REST interfaces are a very fuzzy architectural notion, in much the same way that MVC or client/server architectures are ideas and not specifications. There is no spec for what verbs a REST interface must represent!

I gotta run to work, so this answer is going to be short, but I guess I should have be more clear in my post. This is not what *I* define as REST, HTTP+POX, and SOAP, or believe the “correct” definitions are.

However, in my opinion, based on talking up eBay web services at many places for the past 2.5 years, if you went to a couple of web conferences and polled the attendees on their definitions of the terms, the results would be what I describe above.

I will post more when I get more free time later today, as I am interested in continuing this discussion.

Most of the web services you describe as REST are in fact REST, because a lot of public web services only let you fetch data. They use GET in a RESTful way because all their URIs are safe. But if a service lets you change the dataset it needs to use the other HTTP actions (PUT, DELETE, and POST, the latter of which still confuses me) for that. The best way to do this is to structure the URIs into resources, so that if you want to get the weblog entry at URI “/weblog/posts/100″, you send a GET request to that URI, and if you want to delete that entry you send a DELETE request to the same URI.

So the Amazon E-Commerce Service is almost entirely REST. It’s full of URI query-string options for searching and getting info from the Amazon product database,. Any query you can construct from the options describes a resource (a particular slice of the database) and GETting it gives you an XML depiction of that resource. But it also exposes some options called CartAdd, CartClear, etc. which store data in your shopping cart on the server side. This violates REST.

GET is for getting resources, and using it to make changes is dangerous. You may remember the flap that resulted when Google released a browser-side cache that followed links. It followed links like “/weblog/delete?id=100″ and triggered actions the user hadn’t requested. “Cart” can be considered a resource that you can add, modify, delete, etc. but “CartAdd” is an operation. And in fact you’ll see people saying that AECS is not REST for this reason.

Near as I can tell HTTP+POX was invented by REST eggheads to shift off a bunch of services that didn’t meet the REST criteria, like the del.icio.us API, the Flickr API, the non-RESTful part of AWS, and so on. But since the term was coined by REST fanatics as a wall around REST, there’s no clear line of demarcation on the other side.

HTTP+POX services and SOAP services both have rules about what XML documents you can send under what circumstances. You could have a pathological service that was more idiosyncratic than SOAP in the XML it accepted. I’d say that would be worse than SOAP, and I wouldn’t want to call it HTTP+POX because then SOAP would be HTTP+POX too. That’s why I’m looking for another way to make the distinction. There might be no sharp distinction at all, just a gradient that includes SOAP near the far end.

Send me and Sam email if you’d like to continue this discussion and help us with the definitions.