an HTTP request goes through a bunch of infrastructure (browser, local cache, proxies, CDN, server-side cache, web server, application layer)
this involves a number of different products by different vendors
the one thing that binds those different products is the standardised behaviour of HTTP
that behaviour is what allows HTTP to scale enormously, specifically with regards to caching
you're proposing to discard all that and essentially invent your own protocol, discounting all the help you may get from all the existing infrastructure
You're only making your own life more difficult for little to no advantage that I can discern. Do not underestimate the advantage of a properly implemented HTTP API when you find that you need to start scaling up. It's not that easy to throw a CDN or additional servers into the mix when you've painted yourself into a corner with a custom protocol that is uncacheable/unproxiable/unwhateverable.
This is the type of "what about" comment I was hoping to get.
I think I've conflated the RESTful approach to utilizing the capabilities of HTTP with using HTTP verbs and status codes to satisfy the CRUD requirements of a web app.
I'm going to have to think about separating some concepts more clearly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In other words:
You're only making your own life more difficult for little to no advantage that I can discern. Do not underestimate the advantage of a properly implemented HTTP API when you find that you need to start scaling up. It's not that easy to throw a CDN or additional servers into the mix when you've painted yourself into a corner with a custom protocol that is uncacheable/unproxiable/unwhateverable.
This is the type of "what about" comment I was hoping to get.
I think I've conflated the RESTful approach to utilizing the capabilities of HTTP with using HTTP verbs and status codes to satisfy the CRUD requirements of a web app.
I'm going to have to think about separating some concepts more clearly.