What am I not understanding about REST?

Question

I'm building a framework and want developers who build with it to have the ability to allow parts of it to both share data with other sites and allow other sites to add/edit/delete data.

For example, if someone makes a site that has book reviews, authors, quotes, code examples, comments, etc. the developer could make e.g. "book reviews" read-only for other sites and "comments" readable by other sites and writable by certain sites/users. The idea is to use the framework to build applications that can easily be interconnected with other applications.

I envision enabling all interaction with the site via POST and GET which would look something like this:

• /books.php?category=ruby (returns an XML collection of books about ruby)
• /books.php?id=23 (returns the XML for a specific book)
• /books.php?action=add&title=AdvancedRuby&description=....&securityId=923847203487
• /books.php?action=delete&id=342&securityId=923847203487

Other applications could also "discover and consume" what a certain site has to offer by doing this:

• /discover.php (returns XML of all public classes and actions available)

Really this is all I need to enable the framework to be a way for developers to quickly create loosely connected sites.

What I want to know is, before I begin implementing this, are there significant/interesting parts of REST that I do not yet understand which I should be building into the framework, e.g.:

• REST requires GET, POST, PUT and DELETE. Why would I ever need "PUT" and "DELETE"? Am I locking myself out from taking advantage of some standard if I dont' use these?
• My "discover.php" file functions similarly to a WSDL file in web services. I am surprised in descriptions of REST there seems to be no standardized way of discovering the services that a RESTful service offers, or is there?
• If a client website tries to e.g. add a book to a server website and does not get any "success" response back, it would simply try again until it got a response. The server website would simply not add the same book twice. This is my understanding of data integrity in REST, is there more to it than this?

• eventually I want to have multiple sites that have the same rich classes e.g. "BookReview" so that a client site would be able to execute code such as this:

  $bookReview = new BookReview("http://www.example.com/books.php?id=23"); $book->informAuthor("a comment about your book review was posted on our site...");

and the server site would send an e-mail off to the author of that review. Is this type of type interaction a component of the RESTful philosophy or is REST simply the exchange of data via XML, JSON?

Answer 1

From the RestWiki:

• A GET to an identifier means "Give me a copy of your information in a particular document format".
• A PUT to that identifier means "Replace your information with mine".
• POST adds information, and
• DELETE eliminates information.

With this in mind, applying it to your application should be quite straightforward.

Answer 2

With the Restlet framework, we exactly tried to provide this level of abstraction above HTTP details and to make REST concepts more concrete (many have a matching class like Component, Connector and Representation): http://www.restlet.org/

We are pragmatic coders and our users develop real-world applications with our RESTful framework (for Java and GWT). REST supporters aren't all pedantic but there is a learning curve like for every major technology.

Answer 3

REST is an interesting and potentially useful technology, but unfortunately it seems to attract the most pedantic collection of developers.

It seems they would rather an implementation follow the REST dogma to the letter even though it means a total loss of functionality. Any deviation from pure REST will be treated as heresy.

Answer 4

I suggest you read this post by Roy Fielding.

A highlight:

• A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

• A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].

You certainly can be successful using a RPC-like approach as you describe and it's easier to grasp than a 'proper REST API'. The most misunderstood aspect of REST is that, once defined, it should automatically work, you should not define go to this URI using this method to get that answer, that should all be implied by the media types you are delivering plus a means to let clients know where to find the relevant resources.

Answer 5

I'll take a stab at what it might look like RESTful.

/books.php?category=ruby

GET /search?type=books&category=ruby

/books.php?id=23

GET /books/23 (or /books/23.xml)

/books.php?action=add&title=AdvancedRuby&description=....&securityId=923847203487

POST /books
title=AdvancedRuby&description=A+great+book...

/books.php?action=delete&id=342&securityId=923847203487

DELETE /books/342

Many developers stick to GET and POST in which case the last one might be:

POST /books/342
status=Deleted

Answer 6

I find nothing restfull about REST. To me, its a great concept from an abstract point of view for web geeks that do not have to deal with the more gritty coding issues involved in complex HTTP communication.

Wouldn'd it be nice if a REST API was available that abstracted us from all the HTTP. But it doesn't. Instead, REST proponants have to do a sales job to you write such an API with all the attendant problems of debugging and testing.

The day I see a REST 1.0 header, I'll take a second look to find an advantage worth the effort.