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
Posts
6
Posters
27
Views
-
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@activitypub.space shared this topic on
-
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
-
@apps@toot.fedilab.app appreciate the open API but of course be wary of abuse. I would not be opposed to registering for an API key when needed 🙂
-
@HolosDiscover
Sounds good. A lot text about indexing and how it works.
But no Text about what it does and how to use. What UI, Instances?
-
@julian
There's a public API where you can search posts, accounts, hashtags, get trending content, public timelines, and instance stats.
Documentation: https://codeberg.org/tom79/Holos-Discover/src/branch/main/doc/api.md
Base URL is https://discover.holos.social. Quick example:
https://discover.holos.social/api/search?q=fediverse&type=posts
No authentication for now, but we may introduce API keys in the future.
-
@apps@toot.fedilab.app do you have an API we can use? It'd be interesting to hook into your search results for fediverse search.
-
#HolosDiscover is back, from a clean slate.
A #Fediverse search engine that uses standard #ActivityPub federation. It follows you like any account, respects indexable flags, #nobot, #noindex, locked accounts. Deletions, edits, blocks are processed instantly through ActivityPub.
You have full control. Block it, mention it with "unfollow", or disable indexing in your settings.
Source code under AGPL-3.0 on #Codeberg.Details: https://discover.holos.social/how-it-works
Account: @HolosDiscover
-
Yes, very likely.
When I built the core software for a bank more than a decade ago, I did the same.
-
There isn’t anything that says my server should return the latest known state of a post, including my interactions with it.
And sure, I can refetch any activity from the inbox via proxyUrl (except non-public), but nothing guarantees my server will add the current remote state of a post to its internal representation and return this.
So this forces a thick client situation, to have what should be fairly standard User Experience.
-
Of course implementations may vary but the spec isn’t clear, so let’s improve this, yeah! https://github.com/swicg/activitypub-api/issues/52
