Alright, I think my previous message 👆 may have been a little unfocused, so let me rephrase: For those who have done a lot of work in traditional RESTful web applications --think server-rendered HTML, API endpoints that return HTML from a GET request and accept input via HTML form POSTs, query parameters, path parameters-- how do you organize the inputs to your app? What are your rules of thumb for what kind of input goes into which part of the request? What belongs in a query parameter? What belongs in a URI path parameter? What should be sent in the form of an input field in a form? All of these things COULD be used to communicate change to your database. ALL of them COULD be used to send the literal values that are going to get transacted into the database. All of them COULD be used to modify or supplement or provide additional context to the behavior of your server while it tries to figure out what to do with the data being sent to it. But what are the HTTP tools we have at hand best suited for?
don't put anything sensitive in the route or query param
Why? They are equally encrypted as the body is. Or are you thinking more of XSS or leaking information logs?
It's considered bad practice because URLs are logged all over the place (referer header, proxy servers, web logs, browser history, bookmarks) and can be accidentally shared by the user. XSS is a consideration but only in as much as anything not explicitly hidden from JavaScript is insecure
I'm not saying never do it (e.g. SSO integrations tend to put short lived tokens in URLs), but it's one of those situations where you have to understand the rule to know when it's OK to break it
Some web apps just put the standard bearer token as a query param in JWT form (which is a bad idea)
https://stackoverflow.com/a/31261026 I think that partially answers your question pretty well
My simple rule of thumb is:
> When a REST endpoint is straightforward (ie it doesn't need complex/nested parameters etc) then make the endpoint easy to call from curl and from standard HTML forms (`application/x-www-form-urlencoded`).
That's it.
From this rule:
• I'll often allow parameters to be both GET and POST params (no need to limit the user! "Be liberal in what you accept from others").
• I favour standard HTML POST forms (`application/x-www-form-urlencoded`) over JSON/gRPC/Avro body.
This approach:
• makes it easy to use the endpoint from any programming language,
• not require any dependencies/libraries
• easy to build a UI for the endpoint in HTML
• Easy to debug with tools like curl/Postman.
Super helpful link @flauwekeul, thank you!
@andyfry01 here are my thoughts on query params, not sure this is what you're asking about https://drewverlee.github.io/posts-output/2020-8-17-uri-parameters-to-datalog
I can't believe that was 4 years ago wtf