N/A
A Critical Analysis of REST APIs for "Transaction Systems"
Disclaimer: This is not an academic paper, it is simply a set of observations I have made during my fairly long journey with Web (HTTP) based business systems. You don't have to agree with it at all :-)
Introduction
Since everybody in IT who haven't slept under a rock the last 10 years know, REST has become almost synonymous with good Web API design (although most developers tend to refer to their designs as "RESTful" to provide some latitude in the interpretation what REST actually is...).
In spite of that, I have for a certain class of applications which we can call "Transaction Systems" come to the conclusion that REST may not always be the most logical choice for Web APIs. The reasons are briefly described in the following sections. Transaction systems (using my vocabulary NB), for example include B2B order/invoicing and bank-to-bank payments.
Web Services, SOAP, and XML are Obsolete!
Indeed, after more than 10 years with SOAP, XML and XML Schemas, I have finally closed that door. However, that's not equivalent to "Everything was wrong with Web Services" which REST advocates often claim. You can safely drop SOAP and replace XML with JSON, but the underlying RPC-concept still has plenty of mileage left, which I have elaborated on a bit further down in this paper.
REST - Stateless Operation
Stateless operation is great but transactions are typically not stateless so it is hard to see that REST has anything special to offer here. Existing, non-REST transaction systems usually do not depend on Web server state either.
REST - Asynchronous Operation
This is a more complex issue but if I understand the REST philosophy correctly, a slowly processing transaction request should not block until it is ready, but rather return HTTP 202 and a header holding a URI to a location where the result may be queried for.
IMHO, this greatly complicates the design in both ends; the server must still continue with the processing (albeit in the background) including dealing with possible time-outs, and then when a result is ready move it to a handler for the previously calculated URI.
For clients that are not browsers, but "Business Systems", it gets worse; after sending the request, the client needs to start a process for querying the result using the previously received URI, and finally pairing the result with the original request. There may of course be a time-out here as well.
To me this looks pretty much like reinvented SMTP, using HTTP and Web servers.
Recent EU directives (SCT Inst) require payment transactions to finish in less than 10 seconds while card network operations already typically take less than 1 second which (IMO) does not motivate asynchronous operation between "machines". Of course there are some slow (mainly mail based), transaction systems out there which could benefit from a scheme like above, but that does not (at all) imply that you need to buy into in the whole REST package as well.
REST - HTTP Bindings
REST is claimed to not be limited to HTTP. This may be true, but it is not entirely obvious how a scheme based on URIs, HTTP Header Parameters, HTTP Verbs, and an Optional Request Body, could be translated to other transports.
REST - WebSocket
Although not directly related to our class of applications, REST appears to be entirely incompatible with event based communication including WebSocket and postMessage().
REST - Serialization
A common feature of transaction systems, is storing transaction data. Since the meaning (semantics) of a REST request is not uniquely defined by the "payload", a complete store operation would (presumably) include HTTP verb, URI, and HTTP headers as well.
It is for sure doable but it seems rather messy compared to serializing "Old School" typically self-contained XML messages.
REST - Signed Requests
Believe it or not, but there is currently no established standard for signing REST requests.
Well, when you look more closely into the matter, you will find that a major hurdle is that a proper signature scheme should sign all elements characterizing the semantics of a request which for REST also include HTTP verb, URI, and HTTP headers, making canonicalization awkward.
If you to the above add countersigned messages which are a useful feature in transaction systems, you will likely end-up with an ugly mixture of JSON and non-JSON data.
An example of a REST signature scheme used by Amazon.com: http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html.
Another Take on "Transaction System" APIs on the Web
The following paper outlines a scheme called YASMIN which I consider a viable alternative to REST based APIs: https://cyberphone.github.io/doc/web/yasmin.html.
Unlike REST, YASMIN was also designed to support event based communication which addresses an entirely different set of Web applications.
V0.6, A.Rundgren, 2017-01-27