Getting real with REST

I browser around for a decent example of a simple, fully REST API, to no avail. Checked on stackoverflow as well. The best I've seen is this post. Despite this, I still don't get the point. Let's take an example of an application that we all know: wikipedia.

Suppose we want to create a REST API for wikipedia. We expect the following verbs:

GET /wiki/Article_name: obtains a specified page
DELETE /wiki/Article_name: deletes the page
POST /wiki/Article_name: creates a new page
PUT /wiki/Article_name: updates a page.

Fact is: when you use wikipedia with your browser, you don't use a REST interface to navigate it. I am pretty sure that when you update a page, you never use PUT (although you are technically creating a new revision of a page, so POST makes sense). Similarly, when you delete a page, the browser does not send a DELETE.

My questions are:

is REST also an interface "for the browser" or just for scripts ?
should we see the HTTP world exclusively through the eyes of a REST representation? are things like GET /foo/?page=bar&action=delete still a valid point of view, or horrible mistakes of the past never to be done again ?
should the web access and the REST interface be intermingled or separate? For example, suppose you have a AddressBook application. You can browse the address book with GET /people/, and with GET /people/1523 you obtain that single person information on the browser, maybe in a nice printable HTML. If you want to modify his card, you would do (RESTfully) PUT /people/1523, or instead have like PUT /api/v1.0/people/1523 ?
could anyone please convince Roy Fielding to get human and provide a "5 years old child" example for a decent (in his opinion) REST API, inste

rest

Edit Report

Remember - REST is nothing more than a set of architectural constraints for distributed computing, independent of any underlying transport protocol. When evaluating the RESTfullness of a client-server interaction, you're really checking to see if one or more of these contraints are broken.

is REST also an interface "for the browser" or just for scripts ?

When you browse Wikipedia with Firefox, you're controlling a REST client. The lack of support for PUT and DELETE doesn't detract from the RESTfullnes of the interaction because the meaning of HTTP verbs is outside the scope of REST. A more questionable point might be the way that sites and browsers support sessions. When each request must be understood in the context of a session, you could say that the constraint of statelessness of requests is broken.

should we see the HTTP world exclusively through the eyes of a REST representation? are things like GET /foo/?page=bar&action=delete still a valid point of view, or horrible mistakes of the past never to be done again ?

AFAIK, this doesn't in itself break a REST constraint, unless the same URI/verb combination does two different things. In that case, you'd be breaking the uniform interface constraint. I'd say this approach is bad from the perspective of deviating from the intent of the HTTP protocol, but not from the perspective of REST.

should the web access and the REST interface be intermingled or separate? For example, suppose you have a AddressBook application. You can browse the address book with GET /people/, and with GET /people/1523 you obtain that single person information on the browser, maybe in a nice printable HTML. If you want to modify his card, you would do (RESTfully) PUT /people/1523, or instead have like PUT /api/v1.0/people/1523 ?

I don't see a problem with a RESTful API working differently for browsers and

answered 2009-10-10T14:37:01.663

1 Answer

Your Answer