About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
It's possible to avoid using HTTP verbs, but I would not call this approach RESTful. Depending on the context it can be a good solution, but, probably, not a universal one. One problem that I see with this approach is the fact that to act on a request you need to parse the request body because the standard HTTP data does not provide enough information. For example, if you need to route some requests to a different backend using NGINX, you will have to parse the request body instead of using URL-based pattern matching.
Regarding the URLs in the logs, what about configuring your servers so that they don't log requests? And I don't see a big problem with it.
Fair criticism - as we currently implement RESTful solutions.
I came to question why a RESTful solution (the purview of the app) should depend on the communications protocol (HTTP).
Turning it inside out, what if the available HTTP status codes don't provide enough information on the nature of a response to provide an effective solution ?
or,
Why can't/shouldn't we have a RESTful solution without relying on HTTP ?
About me: software developer who is into JavaScript and NodeJS and constantly working on one or another side project and/or open source. I have a blog at https://alex-rudenko.com
You can do it without relying on HTTP but you need to follow constraints: en.wikipedia.org/wiki/Representati... In your suggested approach, I see the following broken constraints: Cacheability (you can build your own without relying on HTTP though), Uniform interface (because when you GET a web page in the browser, you should be able to update it with a PUT back). You can achieve uniform interface but, then, I believe your client should not be the browser itself but something running inside the browser. But that's all vague anyway. More important is that you will be building a protocol on top of HTTP, you will not be able to use some the standard tools and conventions.
It's possible to avoid using HTTP verbs, but I would not call this approach RESTful. Depending on the context it can be a good solution, but, probably, not a universal one. One problem that I see with this approach is the fact that to act on a request you need to parse the request body because the standard HTTP data does not provide enough information. For example, if you need to route some requests to a different backend using NGINX, you will have to parse the request body instead of using URL-based pattern matching.
Regarding the URLs in the logs, what about configuring your servers so that they don't log requests? And I don't see a big problem with it.
Fair criticism - as we currently implement RESTful solutions.
I came to question why a RESTful solution (the purview of the app) should depend on the communications protocol (HTTP).
Turning it inside out, what if the available HTTP status codes don't provide enough information on the nature of a response to provide an effective solution ?
or,
Why can't/shouldn't we have a RESTful solution without relying on HTTP ?
You can do it without relying on HTTP but you need to follow constraints: en.wikipedia.org/wiki/Representati... In your suggested approach, I see the following broken constraints: Cacheability (you can build your own without relying on HTTP though), Uniform interface (because when you GET a web page in the browser, you should be able to update it with a PUT back). You can achieve uniform interface but, then, I believe your client should not be the browser itself but something running inside the browser. But that's all vague anyway. More important is that you will be building a protocol on top of HTTP, you will not be able to use some the standard tools and conventions.
Thank you. This is precisely the kind of "what about" comment I was hoping to get
Several ideas working their way through my thoughts right now between your comment and David Zentgraf's, above.