re: RESTful without HTTP Verbs VIEW POST

TOP OF THREAD FULL DISCUSSION
re: If your primary concern is information expose in server logs (why Iā€™m not sure, but okay), reconfigure your server to log less information. Done. Y...
 

In other words:

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

code of conduct - report abuse