Is REST suitable for document-style web services?

Question

RESTful and document/message-style seem to be two trends to implement web services nowadays in general. By this, I mean REST vs SOAP, and document-style vs RPC-style.

My question is how compatible REST is with document-style web services. From my limited knowledge of REST, it is utilizing http GET/POST/PUT/DELETE verbs to perform CRUD-like operations on remote resources denoted by URLs, which lends it into a more "chatty" and remote-method like style, aka RPC style. On the other hand, document-style web services emphasize on coarse-grained calls, i.e. sending up a batch like request document with complex information, and expecting a response document back also with complex information. I cannot see how it can be accomplished nicely with REST, without declaring only one resource for "Response" and using POST verb all the time (which will defeat the purpose of REST).

As I am new in both document-style and RESTful web services, please excuse me for, and kindly point out, any ignorance in above assumptions. Thanks!

Answer 1

Your understanding of REST is misguided. This is not surprising nor your fault. There is far, far more mis-information about REST floating around on the internet than there is valid information.

REST is far more suited to the coarse-grain document style type of distributed interface than it is for a data oriented CRUD interface. Although there are similarities between CRUD operations and the HTTP GET/PUT/POST/DELETE there are subtle differences that are very significant to the architecture of your application.

I don't think you mean REST over SOAP. It is possible to do REST over SOAP, but to my knowledge nobody does it, and I have never seen an article talking about it.

SOAP is usually used for "Web Services" and REST is usually done over HTTP.

Answer 2

REST is really meant to be used with documents as long as you consider your document a resource.

GET allows you to retrieve the document. Obviously.

POST allows you to create a document. No need for your API to require the full content of the document to create it. It is up to you to decide what is required to actually create the document.

PUT allows to modify the document. Again, no need to force the client to send the whole document each time he wants to save. Your API may support delta updates sent through PUT requests.

DELETE obviously deletes the document. Again, you can design your API so that deletes does not actually destroy every bits of the document. You can create a system similar to a recycle bin.

What is nice with REST and working with documents is that the server response contains every information needed to understand the response. So if a new resource is created, you should send its location, same if a resource is moved, etc. All you have to document is the data types that will be used (XML formats, JSON, etc.)

Standard HTTP methods are just there because their behaviour is already defined and allow clients to easily discover your API as long as they know the URI.