@emilis@jeder I mean sure but passing all of your arguments to a request in body json seems convenient. GET doesn't get a body right? Or is there some other tool for that which I'm missing?
@lunareclipse@jeder "convenient" is relative. It's going to be conveniently make me pull my hair out because all the context of the request is stripped out and just put into the body. And in the body, it's non-standard, I wouldn't know what I'm looking for.
Also, why stop there? You don't even need routes, those can move into the request body as well. I know this sounds absurd, but that's also how putting context in the body when there are more standard areas for it.
In terms of "GET body", there are query parameters. I can imagine those might not seem ideal given the perspective from this post, but knowing more about the standard makes it all fit in. Like, query params for GETs are generally supposed to be filters, or some sort of modifier. Because GET hints that you can, well, get the resource under that URI (specific or list) (See: datatracker.ietf.org/doc/html/rfc7231#section-4.3.1).
@lunareclipse@emilis@jeder Making all verbs POST breaks one of the basic REST principles, where GET should be used for read, POST for creating new data, PUT for idempotent data upserts, DELETE for deletion and so on
@natty@lunareclipse@jeder Also just wanna add context for POST/PUT since POST can also, according to the spec, be used for mutating data fully or partially.
@emilis@lunareclipse@jeder@natty would POST for everything be as horrifying if you weren't working with resources and were instead working with procedures