Article:		Second Generation Web Services
Subject:		REST ist fine, but...
Date:		2002-02-25 23:50:56
From:		Willy Müller
Being able to access objects by an URI is fine and desireable in many circumstances, and REST might work in situations where I want to save, read or delete data. You can use the HTTP operations to mimik database operations. But are the semantics rich enough to handle all we want to do? What if I want to use a web service for rotating a SVG object by an angle of 30 degrees? What if the POST operation was part of a distributed transaction that has to be rolled back? How do I POST an email? After all, even the oldfashioned forms of the times of paper and pencil are nothing but a kind of RPC. A filled in oder form sent to a compony is ment to initialize a process that will eventually return me the products I ordered. (Otherwise I'm not happy.) Only the fact, that I send a message by mail, by email, by HTTP or some other transport mechanism does not make it more declareative, neither does the fact that the operation is hidden in an URI or a basic operation of HTTP. A SOAP message could be seen as a declaration of the intent of the user and a kind of contract with the service provider what he will get. As user I like clear contracts. It makes life easier. Are REST and SOAP really either-ors? You can easily expose objects using URIs that have been stored using SOAP. You can use HTTP-POSTs to send SOAP messages... Willy Müller

Previous Message

Next Message

• REST ist fine, but...
  2002-05-19 13:14:04 Ron Wolf [Reply]
  
  I'll admit that this is the 1st time that I've heard of REST as such, but the data-centric vs. API centric 'debate' has been going on for a long long time. Fact is, you need both. REST by itself does not make a system. Sure it's a good idea to have self-naming data and simple standardized access methods. This is the core of triumph of relational database (SQL).

  
  Extending the data model to the network with XML makes a lot of sense. But to think of this as a system solution is naive. First off, just as databases change (adding columns, the meaning of existing columns evolves, ...) XML definitions (DTDs and semantics) will also be evolving living things. The tower of Babel may be better documented, but it keeps growing. In this regard REST has nothing over SOAP.

  
  Secondly, and more fundamentally, at some point action needs to be taken. Action requires agreed upon sematics. And action is frequently more than insert this file, access that one. The database world partly addressed this via triggers. But the real solution has proven to be application servers with very complex semantics; real life is complex, sorry.

  
  Pretty crucial that both the data and the action be clearly defined and agreed on. So, again, if systems are to work together, what is it that REST is really helping?