Rambling on Software

I've been continuing to make my way through a book on REST, and come across the following, in which the author is arguing that one of the advantages of REST is that it reduces the burden of API design:

"... the advantage of the uniform interface of REST ... is that it frees us from having to create a new interface every time a new service is created."

I think that the author is conflating the design of different levels of the system. This is perhaps not surprising because he points out elsewhere that while SOAP is designed to run over a variety of different trnasport protocols, REST is intimately associated with HTTP. In spite of this, I think it is still reasonable to assert that HTTP is the transport protocol for REST. Furthermore, there is absolutely no doubt in my mind that the design of the transport protocol is not the same thing as the design of the application protocol. The fact that a REST-based system will use HTTP GET. PUT, DELETE, and POST in well-defined ways does not eliminate the significant task of designing the application level protocol.

To be specific, in a REST-based system, you still need to determine the entities which will make up the system. You still need to determine the right set of attributes for each and the relationships between them. You still need to determine what processes will effect these entities and how they will be changed. This is what the design of the application protocol is concerned with and all of this is a much more challenging design task than sorting out that the DELETE request should delete something.

In my last posting, I noted that we software developers often suffer from the desire to believe that whatever new approach we have adopted is the finally the right one. We need to stop this. Grandiose claims of how much better approach A is over approach B cloud the reality of the situation which makes actual forward progress more challenging. There is no silver bullet. Get used to it.

I'm reading a book about REST at the moment. I'm finding it quite interesting, but like so many issues in software development, there is a tendency to hyperbole. Take the following quote for example: This is because SOAP always uses POST, which can't be cached at any level. This is, almost obviously, false. This is nothing in any of the protocol specifications which prevent a SOAP client from caching the response to a SOAP request using an application specific protocol. So, SOAP can in fact be cached at the application level. Being charitable, I can suppose that the author did not intend to lie. I can suppose that what he was thinking when he wrote the above is that a SOAP response cannot be cached by an HTTP level cache since that would violate the HTTP specification.

Unfortunately, that is not what he wrote. What's worse, many people will read the book and simply accept the statement as written. They will believe that it is not possible to cache SOAP, make design decisions based on the belief that it is not possible to cache SOAP, and possibly effect the design decisions of others by propagating the notion that SOAP cannot be cached.

REST is a fine approach to designing web-based applications. But when people make broad and unsupportable statements about a technology they contribute to a problem that seems to haunt software engineering: taking what should be a rational discussion about the merits of a given technique or technology and turning it into a pointless confrontation where the focus is on who is right rather than what is the most appropriate solution for a given set of constraints.