As I was looking at a large number of so-called REST APIs, I have observed one common pattern in some APIs. They are supposed to be RESTful, but smell SOAPy. Here are some examples.
To get a person, using
GET /path/getPersons?id=subbu
in place of
GET /path/persons/subbu
To create a person, using
POST /path/createPerson?fn=Subbu&ln=Allamaraju&em=subbu@nospam.com
in place of
POST /path/persons?fn=Subbu&ln=Allamaraju&em=subbu@nospam.com
To delete a person, using
POST /path/deletePerson?id=subbu
in place of
DELETE /path/persons/subbu
To update a person, using
POST /path/updatePerson?id=subbu&em=subbu@nospam.com
in place of
PUT /path/persons/subbu/email?address=subbu@nospam.com
and so on.
There are two common themes in all these examples. Firstly, URIs are identifying operations and not resources. That is SOAPy. Secondly, the URI space in these examples is structured such that query parameters provide all the inputs while the response contains the output. That is SOAPy again. These are HTTP APIs, but not RESTful.
{ 3 comments… read them below or add one }
A RESTful version of Amazon’s SimpleDB
Dimitri Glazkov posted a quick comment on the rest-discuss mailing list stating that the design of Amazon’s SimpleDB REST API is just a big welcome to 1999. The technology powering SimpleDB is definitely impressive – no doubt about it. It is a simple-t…
Well, another common practice I’ve seen, is to disguise SOAP in REST by responding, in case of errors (404, 412 and so on) with a single code (500) with the explanation of the error.
sorry, I cut off my comment:
“with the explanation of the error in the response body”