For those people:
- REST is not SOAP
- REST means GET and POST, maybe HEAD, but likely not PUT or DELETE.
- REST means using URIs to identify some, but not all things
- RESTful API authentication involves OAuth or something similar - what, after all, is the other "officially" RESTful way of doing API authentication?
- REST usually means putting "custom HTTP header" information in GET query parameters or the POST body, to avoid defining... custom HTTP headers. Which method is best? The answer varies, depending on your situation.
- REST means returning a custom XML format, but I might be able to (ab)use Atom, and JSON, because it works well with Javascript.
- What is HATEOAS again?
- REST is most usefully practiced on rest-discuss
But maybe the real problem is that no significant application design problem can be solved simply by "using REST". The answer involves actually understanding your design constraints, and meeting real requirements with real solutions.
2 comments:
I don't understand parts of your list, for instance the statements about PUT and DELETE (why not?) and custom XML formats (the essential idea is to use well-defined formats identified by mime types, not a particular one).
* The statement about PUT and DELETE is to do with many Web applications not supporting the actual PUT and DELETE verbs - leading to query parameter solutions (?http_method="PUT" in an HTTP POST for example)
* I think it's fine to use custom XML formats, and indeed, identification by MIME type is good.
In general, the post is not intended as a complaint, but more as the opinion that REST seems to have a wider definition in many people's minds than the one described in Roy's thesis.
Personally, I don't think that's generally a bad thing.
Post a Comment