I like this article, and I think you have made an important realization. In practice I -- along with most people -- have never done a Level 3 REST APIs, because they cost a lot to develop (for API consumers too). But going less than Level 3 does not provide the supposed benefits of a uniform interface. Nor does it even count as "REST" according to its creator. Yet obviously many people see the benefit of using some of the patterns from REST for specific benefits. Examples: content negotiation, hypermedia, scaleability from statelessness and/or cacheability.
I gave up on REST myself. I have taken to using HTTP as just a transport protocol. With a simple interpretation of the contents as a message. Instead of "media types", my client apps know how to work with "message types". These are business-level requests/responses, as opposed to "resources" (which a lot of people believe to be database tables). All messages are sent to a few well-known endpoints of the given API. This does not prevent the API from being scaleable or using content negotiation and hypermedia. But I am not required to use them either. I can start simple and layer on these complexities as the need arises. Since using this strategy, I run into far less situations where I am puzzled trying to figure out how to squeeze my use case into REST constraints. Instead, it's more about puzzling to understand the business's precise problem so I can determine the right messages to add.
I like this article, and I think you have made an important realization. In practice I -- along with most people -- have never done a Level 3 REST APIs, because they cost a lot to develop (for API consumers too). But going less than Level 3 does not provide the supposed benefits of a uniform interface. Nor does it even count as "REST" according to its creator. Yet obviously many people see the benefit of using some of the patterns from REST for specific benefits. Examples: content negotiation, hypermedia, scaleability from statelessness and/or cacheability.
I gave up on REST myself. I have taken to using HTTP as just a transport protocol. With a simple interpretation of the contents as a message. Instead of "media types", my client apps know how to work with "message types". These are business-level requests/responses, as opposed to "resources" (which a lot of people believe to be database tables). All messages are sent to a few well-known endpoints of the given API. This does not prevent the API from being scaleable or using content negotiation and hypermedia. But I am not required to use them either. I can start simple and layer on these complexities as the need arises. Since using this strategy, I run into far less situations where I am puzzled trying to figure out how to squeeze my use case into REST constraints. Instead, it's more about puzzling to understand the business's precise problem so I can determine the right messages to add.
Thanks.
The Fowler link lead to the Fielding link.
Results of those readings are included in my original post as "update 2".
Much appreciated.