3 ms·
I'm okay with it until the database. For http verb, I'm onboard with just using POST for everything. The database is one area that you need more care. Even if
by kardianos 3y ago
I'm okay with it until the database.
For http verb, I'm onboard with just using POST for everything.
The database is one area that you need more care. Even if just SQLite, storage persists and especially if this is for a company, needs to persist past you.
- Supermancho 3y agoUnless there's a compelling reason...like a use case for caching (your server or an intermediate) or high volume (POSTs are larger requests), POST for everything is a good default.
- Ireallyapart 3y ago[dead]
- collyw 3y agoDebugging is easier with GET requests, where you can see what is being sent to the server. It's not a huge win, but it's better than POST for everything in my experience.
- yurishimo 3y agoWhat do you mean? You can inspect POST request payloads in browser devtools just as easily as GET requests.
- collyw 3y agoIt's far faster when you can look at the URL and see the parameters. I have worked on systems with both and I didn't like everything as a POST. If you want to get a page with list of objects with a filter it's a lot easier to copy paste a URL than it is to fart about in developer tools and try top recreate the POST request.
- Supermancho 3y agoIt's also easier to reproduce, for sure. This goes for QA as well as customers, that may not be casually accessing the request (or have access to the logs) for reproducing problematic requests.