savas parastatidis

Why I believe REST is not far from “ProcessMessage” or document-centric WS

Mark Baker linked to this post which talks about how to access O’Reilly’s Safari Bookshelf using a REST API and has some example Java code. This post made me think about the relationship between the “ProcessMessage” approach that Jim and I have been advocating and REST. Are we that far apart? Well, I don’t think so.

In the example, some important piece of information is missing. How could the developer possible know that a) the returned document was XML (ok, check the appropriate HTTP header) and b) that the contents of the XML document had a root element “safari” and a child element “book”? Obviously they read some documentation, human-readable documentation.

What we are saying is that contracts and schema describe the same information in a machine-readable fashion (not semantics, but just syntax and patterns). So, I could actually validate the returned document, before going to the process of trying to read the data in it and reason about it. I could even use the contract to create programming abstractions (if I was afraid of processing XML).

Furthermore, why should an application like this be tied to HTTP? Isn’t the logic shared no matter what the transport protocol is? For example, someone may send the Safari catalogue to me via TCP/IP, email, or even fax it. That’s what Web Services is all about (at least the way I say them).

Finally, how did the application developer know how to construct the URL of the request? Again, some human-readable documentation from somewhere was used. Isn’t this the same as reading some documentation that describes a SOAP message exchange pattern? For example, Request…

<soap:Envelope>

<wsa:To>safari-address</wsa:To>

<wsa:MessageId>uuid:bla-bla-bla</wsa:MessageId>

<wsa:ReplyTo>me</wsa:ReplyTo>

<soap:Body>

<safari:bookshelf-request />

</soap:Body>

</soap:Envelope>

Reply…

<soap:Envelope>

<wsa:From>Safari</wsa:From>

<wsa:To>me</wsa:To>

<wsa:RelatesTo>uuid:bla-bla-bla</wsa:MessageId>

<soap:Body>

<safari:bookshelf>

<!- lots-of-books ->

</safari:bookshelf>

</soap:Body>

</soap:Envelope>

The above is transport-neutral, the contents of the message can be described in a schema language (e.g., XML Schema or RelaxNG), the message-exchange pattern (in this case request-response) can be described in an appropriate WS-specific vocabulary (e.g, WSDL), and tooling can be used to validate messages based on the metadata. Furthermore, I can think of more complex scenarios where I can send the request to the Safari bookshelf and request the results to be delivered to Jim (just by changing the ReplyTo element of the WS-Addressing information headers). But “wait” you say. How do you know that Jim would be prepared to accept a message like this? Well, Jim can describe this in his contract and also advertise policy information which will be restricting the originator of such messages to Safari. And all this information can be processed automatically by software.

I am really keen to hear the RESTferians take on this.

2 responses to “Why I believe REST is not far from “ProcessMessage” or document-centric WS”

  1. Mark Baker
    Savas; something to keep in mind is that there’s REST, and then there’s REST-applied-to-the-Web. What you describe there is in part the former, as it’s just documents being exchanged using uniform semantics. But as it relates to the latter, what you describe breaks it since wsa:To supercedes the Request-URI in HTTP (or the MAIL TO arg in SMTP, or the path/file in FTP, or …). As we’ve discussed before, I believe this is a result of not fully appreciating the critical role played by application protocols in Internet based systems (as demonstrated by referring to them as “transport” protocols). Multi application and transport protocol support is definitely a good thing, and REST permits both, but not in the unconstrained manner you appear to advocate. Consider an HTTP/SMTP gateway; if a document were POSTed to the gateway, the gateway could meaningfully forward that out via SMTP DATA. But if a document were PUT to the gateway, it couldn’t send it via SMTP because SMTP can’t do state replacement. Nor could the gateway submit a request for data via SMTP in response to a GET, since SMTP doesn’t do that. I would be interested in hearing how you’d retrieve data with ProcessMessage, since as we discussed in that looong thread on Jim’s weblog, it can’t do that without additional coordination. BTW, regarding the title of this blog, I believe that REST and ProcessMessage have far more in common than they do with document based Web services, since the latter don’t use uniform semantics.
  2. MikeD
    > For example, someone may send the Safari > catalogue to me via TCP/IP, email, or even fax > it. Thats what Web Services is all about (at > least the way I say them). If somebody sends the Safari catalog to Amazon, the Amazon software wouldn’t know to add the data to their master catalog or remove the corresponding items. The intent of what to do with the document isn’t specified. Maybe it’s to add the items to a customer’s wishlist…