3 ms·
At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet. The cases
by gbear605 11mo ago
At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet.
The cases tend to look like this:
- An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments.
- An endpoint was implemented as a POST endpoint, despite it being an idempotent query for data, since the request body is too large to fit in query parameters. New employees repeatedly come in and are confused why it’s not a GET endpoint, or why it doesn’t modify anything.
- thayne 11mo agoAlso cases where a GET makes more sense, but there is concern about sensitive data in query parameters getting exposed in logs, so POST is used instead.
- venturecruelty 11mo agoYou can always configure your HTTP logger to not log query parameters.
- ghxst 11mo agoFrom a security perspective it is best to assume everything in a GET query is public, it's not always your server logs that you have to worry about, it could also be logs on the clients system (as an example).
- tempest_ 11mo agoA POST could be viewed as creating a "search" which, once given an ID could be retrieved later with a GET. I know this densest really work with ad-hock and cheap queries but it does for more expensive / report style ones.
- JodieBenitez 11mo agoAnd here I am, using JSON-RPC 1.0 over HTTP for internal APIs, skipping all these debates.
- idbehold 11mo agoYou also miss out on standardized HTTP caching mechanisms since those don't work with POST requests.
- JodieBenitez 11mo agoWe don't want this on our use case so it's fine.