Let's have a look at the building blocks of both styles (pic below), with a bit of a twist. Clearly, SOAP style ignores the full CRUD API of its most usual transport protocol - HTTP. Instead of using full set of HTTP API - GET, POST, PUT and DELETE, it uses POST only - just as transport gimmick.
There maybe some good reasons for this, but what it also inherently means is that this very CRUD capability of HTTP needs to be replicated on the service API - after all CRUD change is what we want to do with the service.
Each service now has to re-implement a definition of CRUD capability by itself! Just by definition of this information interchange, we mandate waste. We do not use what we have and invent something new for the same purpose.
Not only is this an replication and overhead on the service provider side, it also causes an overhead on service consumer side, where each consumer pretend they do not know what they want to do, must "learn" (i.e. discover) the capability set of each service, map it onto their original intent, exchange messages with the service provider and interpret the results. So we have reimplemented the same capability, just made it more complex.
Compare that with simplicity of RESTful approach. No auxiliary messages, no discovery of APIs, each service has the same set of capabilities - HTTP methods. These methods than "transfer" "service state representations" (an instance of resource) from consumer to provider. To know WHERE to transfer and to know WHAT is the relationship of resources - there are URIs, to know HOW to transfer- there're the methods of HTTP. To navigate and relate, there's hypertext. No fancy middle ware needed, short and sweet information exchange using the battle tested infrastructure of WWW.
Now that is some sweet REUSE - SIMPLICITY - CONSISTENCY!
No comments:
Post a Comment