Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
dfox434562yI 100% agree. It’s so annoying when clients don’t support sending JSON params in GET requests.
Since I learned graphQL I have come to really dislike writing/calling rest apis. Every single time you try to use one you have to trudge through badly written documentation if your lucky, if not then you’re on a call with a developer who works on the api team and doesn’t have time to spend talking you through it because they’ve got work to do.
The worst api I’ve ever seen was one where this team wrote a single endpoint so that we only had to maintain just the one.
‘It’s generic’ the team proudly declared. And I was the bad guy for saying ‘But It’s unusable’
It had about 300 parameters, named after what they called things rather than what the company called things.
Some were required.
Some of them would require other parameters to be provided with them.
And passing some parameters would mean you couldn’t pass some of the other ones because it was an invalid combination. No documentation for it because they hadn’t had time to write it in 5 years
crtl52yMaybe no. GET requests do not have bodies thats why u use query params.
Hazarth85572y@crtl you can actually send a body in a GET request and most modern servers will parse it correctly and give you the body. But it's undefined behavior for HTTP and you're not *supposed* to send bodies in GET request... you can.. but you shouldn't...
I'm actually against. using URL paths and QueryParams is much more convenient when using a browser or something like cUrl and so on.
Another magic of GET is that it's idempotent and safe... if you allow people to use bodies in GETs next thing you know junior devs will start to misuse it and start posting bodies and updating data from GET requests...