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.
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.