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.