guefra
Jeff GeerlingOh the number of times I'd have to deal with that using APIs...
https://infosec.exchange/@malwareminigun/115226987647548832
https://infosec.exchange/@malwareminigun/115226987647548832
Pawan Dubey@geerlingguy GraphQL slowly slinks to the back of the room.
Kusuriya (kk7hut)@pawandubey I wish graphql was ashamed over this
Malcolm Herbert@geerlingguy same in the unix scripting world - emit an error message on stderr buried in other crap and exit with a 'success' code ... drives me nuts ...
Krishean Draconis@geerlingguy there's an api where i work that you have to pass an 
Accept: application/json header to, some errors come back formatted as json as you would expect, other errors come back as text/html 
DrScriptt@geerlingguy @malwareminigun I believe that HTTP(S) should be an integral part of the stack and not just a stacked transport.
Billy O'Neal@drscriptt I'm sorry but the entire DoD model is based on a lot of stacked transport. Given how complicated delivering the security guarantees is I think we should be happy that we don't have to intertwine that with most of the actual protocol bits too.
(That technically HTTP3 defacto requires TLS because a lot of internet firewalls wouldn't route QUIC otherwise notwithstanding)
@malwareminigun I was referring to how HTTP(S) supports more than just a transport.
Conditional requests, HEAD vs GET, PUT, UPDATE, etc.
Different result codes for different results, redirection, declaration that something is gone.
HTTP(S) is far more than just a transport.
stfn@geerlingguy recently I had to work with an API with which everything non-200 was just 400. Bad request? 400. unauthorized? 400. Daily quota exceeded? 400. Better than 200 with a json error but still a pain