This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Protocol Building

Stefan Tilkov,

In a comment, Mike Glendinning (who really needs to get a blog of his own) challenges my claim that you end up building your own protocol when using web services instead of relying on an existing one when using RESTful HTTP.

As usual, I think Mike is right to a certain degree — when you build applications using RESTful HTTP approach, there is still a lot of application-specific behavior that is not defined by HTTP or REST. But there is a lot of application behavior that is part of the pre-defined protocol. Let’s take identification (URIs) and hyperlinks as an example. If I build two systems, each of them responsible for maintaining its own data elements, and a data item in System A is associated with one in System B, the approach I take is very different in the web services and REST worlds. Let’s use the systems “ContractManagement” and “Partner” as examples, with the “Contract” and “Partner” as the managed entities.

  • In the web services approach, there’ll be operations like getPartner(id: PartnerIdType) : Partner and getContract(id: ContractIdType) : Contract. I can now save the ID of a partner as part of a contract and vice versa. To store and resolve this reference, I have to know the type of ID, the endpoint of the service and operation to invoke, and I need to be able to interpret the return type. Resolving references works according to a protocol I’ve just defined, and which is probably very different for distinct entities even within a single system.
  • In the RESTful HTTP approach, every entity (that is supposed to be externally accessible) would have its own URI, so I need to be able to store URIs. The operation is HTTP GET, the “endpoint” is included in the URI. I still have to understand the format, of course.

This example shows that at least for the case of resolving a reference, REST/HTTP includes a standardized “protocol” that is extremely useful in almost every scenario you can possibly think of. The same is true for many other aspects that are part of the RESTful HTTP world — updating, creating, and deleting resources, or even triggering arbitrary processing; selecting one of many available formats; handling common error scenarios. In the web services world, I need to invent a lot of this myself — I concede there are things the web services stack standardizes which have no analogy in RESTful HTTP, but I still claim that those parts that are standardized yield many more benefits.

It’s my experience that practically everybody who spends some time discussing the relative merits of web services and REST/HTTP agrees that being able to identify “things” in a consistent manner is very useful. A URI is only useful if I can do something with it, which immediately leads to a common (“uniform”) interface. Being able to do a GET on resources immediately poses the question of whether everybody wants to see a resource in the same way … continue this for a while and you’ll inevitably arrive at REST, or something very similar to it.