A Critical Analysis of REST APIs for "Transaction Systems"
: This is not an
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 :-)
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.
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"
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.
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.
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 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.
Although not directly related to our class of applications,
REST appears to be entirely incompatible
with event based communication including
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.
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.
Another Take on "Transaction System" APIs on the Web
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