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. You don’t have to upend the entire HTTP philosophy just for that. A great benefit of a RESTful architecture is its standardization. You don’t have to reinvent the wheel and teach it to every new developer. If you’re vaguely familiar with RESTful conventions, a RESTful API is almost self-documenting. That can save a lot of headache down the line. Not to mention standard behavior of caching and such. You’re basically locking yourself out of the synergies of the existing RESTful paradigm which could enable you to develop and scale quickly.
Sure, you could relegate HTTP to be a mere transport mechanism and implement your own "RESTful" protocol on top of that. Does that provide any advantage? Does it allow you to easily switch the transport layer to something else down the line? Is that a foreseeable requirement? Also see Inner-platform effect.
Fair point on the destination server.
What about the hops between?
And to clarify, the question of server log content only began the thought process; it's not a motivating factor for making a change.
I would question why the little bit of information that may appear in server logs may in any way lead to breaches of any sort in the first place. If your security depends on the exact URL structure of your server being secret, your security is non-existent.
"Hops in between" for HTTP that matter at all to this discussion would only include SSL-terminating HTTP proxies, and they can log the fully payload if their operators so desired and there's nothing you could do about that. Presumably any such proxies would be fully trusted by either the server or the client or both. So for our purposes, intermediate hops are irrelevant.
Encryption is only applicable in end-to-end scenarios, in which case intermediate hops are totally irrelevant - you either don't have them at all, or they're just TCP proxies / IP routers which see nothing but the TCP/IP headers.
If you have a ssl-terminating proxy (i.e., it intercepts your SSL traffic and re-encrypts it to relay it to the final destination) it can log everything.
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.
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. You don’t have to upend the entire HTTP philosophy just for that. A great benefit of a RESTful architecture is its standardization. You don’t have to reinvent the wheel and teach it to every new developer. If you’re vaguely familiar with RESTful conventions, a RESTful API is almost self-documenting. That can save a lot of headache down the line. Not to mention standard behavior of caching and such. You’re basically locking yourself out of the synergies of the existing RESTful paradigm which could enable you to develop and scale quickly.
As a thought exercise, why should a RESTful architecture depend on HTTP ?
Sure, you could relegate HTTP to be a mere transport mechanism and implement your own "RESTful" protocol on top of that. Does that provide any advantage? Does it allow you to easily switch the transport layer to something else down the line? Is that a foreseeable requirement? Also see Inner-platform effect.
Good read. Thank you.
And the somewhat related en.m.wikipedia.org/wiki/Not_invent...
Fair point.
Yep, I agree here. This seems like a lot of work to avoid an issue that should be solvable by a configuration change on your webserver.
Fair point on the destination server.
What about the hops between?
And to clarify, the question of server log content only began the thought process; it's not a motivating factor for making a change.
I would question why the little bit of information that may appear in server logs may in any way lead to breaches of any sort in the first place. If your security depends on the exact URL structure of your server being secret, your security is non-existent.
"Hops in between" for HTTP that matter at all to this discussion would only include SSL-terminating HTTP proxies, and they can log the fully payload if their operators so desired and there's nothing you could do about that. Presumably any such proxies would be fully trusted by either the server or the client or both. So for our purposes, intermediate hops are irrelevant.
Thought that encryption applied to the POST payload, but not the information appearing along with the URL (GET parameters?).
Encryption is only applicable in end-to-end scenarios, in which case intermediate hops are totally irrelevant - you either don't have them at all, or they're just TCP proxies / IP routers which see nothing but the TCP/IP headers.
If you have a ssl-terminating proxy (i.e., it intercepts your SSL traffic and re-encrypts it to relay it to the final destination) it can log everything.
There's nothing in between.
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.