On a fediverse server with a versioned client API, what would you expect to happen if an API call is made with a version number higher than what the server supports?
General Discussion
8
Post
6
Autori
2
Visualizzazioni
-
On a fediverse server with a versioned client API, what would you expect to happen if an API call is made with a version number higher than what the server supports? Should it return an error? Should it take it to mean its highest supported version? Something else?
The API isn't RESTful, the version number is global for all methods (endpoints) and has the format "major.minor".
-
undefined julian ha condiviso questa discussione su
-
On a fediverse server with a versioned client API, what would you expect to happen if an API call is made with a version number higher than what the server supports? Should it return an error? Should it take it to mean its highest supported version? Something else?
The API isn't RESTful, the version number is global for all methods (endpoints) and has the format "major.minor".
Hi @grishka,
using highest sounds like best effort and makes most sense to me. -
Hi @grishka,
using highest sounds like best effort and makes most sense to me.@mro but what if there are incompatible changes that the app doesn't expect? Like some object having a different format, or some method behaving differently
-
On a fediverse server with a versioned client API, what would you expect to happen if an API call is made with a version number higher than what the server supports? Should it return an error? Should it take it to mean its highest supported version? Something else?
The API isn't RESTful, the version number is global for all methods (endpoints) and has the format "major.minor".
@grishka Return an error that tells the client it's used an unsupported version.
By definition, the server does not know the semantics of the call the client made, so trying to guess and return something in the hope it's correct takes us out of the realm of engineering and into clairvoyance.
-
@grishka Return an error that tells the client it's used an unsupported version.
By definition, the server does not know the semantics of the call the client made, so trying to guess and return something in the hope it's correct takes us out of the realm of engineering and into clairvoyance.
nikclayton@mastodon.social agreed.
It's one thing for a server with a newer API version to be backwards compatible with a request from an older version, but it's impossible to predict the future and handle requests from a newer API client.
Bouncing an error back would be the safest choice.
-
On a fediverse server with a versioned client API, what would you expect to happen if an API call is made with a version number higher than what the server supports? Should it return an error? Should it take it to mean its highest supported version? Something else?
The API isn't RESTful, the version number is global for all methods (endpoints) and has the format "major.minor".
Isn't the convention to put the version in the url? e.g. /api/v3/site
In which case a too-high version gives you a 404 error.
-
Isn't the convention to put the version in the url? e.g. /api/v3/site
In which case a too-high version gives you a 404 error.
@rimu that's for RESTful APIs, mine isn't that because I dislike the concept. I just take the version as the `v` parameter
-
@rimu that's for RESTful APIs, mine isn't that because I dislike the concept. I just take the version as the `v` parameter
@grishka @rimu putting the version in the uri is an older convention and not necessarily a REST(ful) thing either. what i've seen is to use content negotiation via an Accept-Version header
basically if you use conneg then 405 Not Acceptable; if you put versions in uris then 404 Not Found; if you take some parameter or payload then i guess maybe 422 Unprocessable Entity?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@scottjenson @mekkaokereke @stefan
There may be other similar issues, but this one clearly seems to be a problem that is often cited.
-
@scottjenson
@mekkaokereke
@stefanGreat. Just to be really clear. What seems to be the issue is a type of hidden dogpiling or 'brigading.'
A tight group folks who's purpose is to harass someone follow each other, 'the brigade'.
One of them composes a harassing post specifically targeting someone who they @ mention, and post it using "Followers Only" reply controls.
The rest of the 'brigade' piles on.
The post is only seen by the targeted person(s) and the harassers.
-
@mastodonmigration always happy to chat
-
@scottjenson @stefan @mekkaokereke
It is great to see this conversation take off. You did a fabulous job with quote posts and it would be wonderful if this issue could get the same kind of careful attention. Completely agree that a proper requirements driven approach is warranted. Thank you.
-
@stefan @mastodonmigration
Yes, @mekkaokereke and I spoke about to how best present Quote Posts and his advice had a direct impact on what we shipped. We're about to reach out for another round of discussions with a wide range of people (but I don't think we've contacted Mekka just yet)It's so tempting to take the engineering approach and think "this feature will do it!" when we likely need to back up and talk about bigger issues such as culture and moderation.
-
@mastodonmigration But yes, that particular issue, I have not heard/seen any updates either.
-
I wonder if @scottjenson might be interested in connecting with
@mekkaokereke, that is, if he'd like to share some thoughts.(Unless you two already spoke, in which case, please disregard!)
-
On the subject of improving Mastodon. This may be an opportunity to rekindle developer attention on the 'Followers Only' dogpiling harassment vector. Felt like some progress on the issue was made back in November, but don't know where it stands now.
cc: @stefan
