User avatar
luna the doggie neofox_snug therian @lunareclipse@snug.moe
3y
The misskey/foundkey API is terrible - lacks documentation and the names and categorization of endpoints don't make sense a lot of the time
3
1
0
0
User avatar
Jeder neocat_floof_googly_woozy neocat_flag_agender @ eth0 (📞422137) @jeder@miau.jeder.pl
3y
@lunareclipse this is what i call certified misskey moment
⭐1
1
0
0
1

3y
@jeder @lunareclipse it's all POST
1
0
0
0
1
0
0
0
User avatar
luna the doggie neofox_snug therian @lunareclipse@snug.moe
3y
@emilis @jeder what's wrong with that anyway?
1
0
0
0
@lunareclipse @jeder HTTP verbs have meanings
⭐1
1
0
0
1
User avatar
luna the doggie neofox_snug therian @lunareclipse@snug.moe
3y
@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?
3
0
0
0
User avatar
Jeder neocat_floof_googly_woozy neocat_flag_agender @ eth0 (📞422137) @jeder@miau.jeder.pl
3y
@lunareclipse @emilis GET gets url args
👍1
1
0
0
1
User avatar
T0╳F03Æ @T0xF03AE@snug.moe
3y
@jeder @lunareclipse @emilis

Then there is the Auth header for authentication, the accept harder for content negotiation etc.


There are also PUT, DELETE that can describe things you might want to do with a resource...

And AFAIK according to spec you technicaly Can include a body for GET... It's just not desirable /needed vast majority of the time.

And then there are the status codes and how some people thing always returing 200 is somehow acceptable...
👍1
0
0
0
1
@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).
⭐1
0
0
0
1
User avatar
princess pancake butterfly_​neofox_lesbian @natty@astolfo.social
3y
@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
⭐1
2
0
0
1
@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.
0
0
0
0
User avatar
a @a@pl.nulled.red
3y
@natty @lunareclipse @emilis @jeder ok but what if you weren't doing REST and were instead doing RPC
⭐2
1
0
0
2
User avatar
a @a@pl.nulled.red
3y
@emilis @lunareclipse @jeder @natty would POST for everything be as horrifying if you weren't working with resources and were instead working with procedures
1
0
0
0
@a @lunareclipse @jeder @natty yes, they fit in the same shape. unless I'm misunderstanding u
0
0
0
0