architecture

2025-04-26T12:43:10.148549Z

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?

mloughlin 2025-04-29T21:53:07.157599Z

don't put anything sensitive in the route or query param

Rupert (Sevva/All Street) 2025-04-30T06:35:37.047969Z

Why? They are equally encrypted as the body is. Or are you thinking more of XSS or leaking information logs?

mloughlin 2025-04-30T13:28:53.017419Z

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

mloughlin 2025-04-30T13:36:41.325949Z

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

mloughlin 2025-04-30T13:37:11.801359Z

Some web apps just put the standard bearer token as a query param in JWT form (which is a bad idea)

👍 1
Abbe Keultjes 2025-04-26T13:57:45.320339Z

https://stackoverflow.com/a/31261026 I think that partially answers your question pretty well

Rupert (Sevva/All Street) 2025-04-26T15:39:23.003929Z

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.

2025-04-26T22:40:38.244079Z

Super helpful link @flauwekeul, thank you!

Drew Verlee 2025-04-27T04:56:33.268969Z

@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

Drew Verlee 2025-04-27T04:56:53.941909Z

I can't believe that was 4 years ago wtf