You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #56 it is possible to provide a sort of compatibility indication server side, but there is no client side preferred version possible.
We're looking into migrating to newer SpaceAPI versions but our hackerspace makes heavily use of the null/undefined spacestate on the backend where it determines that after n minutes, there is no certain state (internet loss, power failure, building torn down).
We also have multiple implementations of several (embedded) clients that reflect the v.013 state, so upgrading to the future v0.15 would most likely break those implementations (of which one is built into a car dashboard).
What would your suggestion be for a client to indicate support for newer versions?
Can these suggestions be documented as well?
In my opinion there are a couple of ways to go about:
look at the user agent requesting the API; very prone to errors
provide a compatibility parameter, I.E. https://ackspace.nl/spaceAPI/?api_compatibility=13,14,15 (simple, but might not work for all implementations)
provide a custom request header: X-API-Compatibility: (not recommended since custom X- prefixes are deprecated since 2012
provide name value pair within the Accept header like described in RFC7231 section 5.3.2(fairly complex) for example, prefer version 15 but accept version 14 as well: Accept: application/json;api=14;q=0.1, application/json;api=15
API endpoints might default to their liking but still provide forward compatibility while clients can specify which version they actually want.
I know this could be regarded as an edge case, but it might assist in migrating to future versions really well where a hackerspace wants to provide the latest and greatest while still pleasing the dozens of IOT devices that might be difficult to upgrade.
The text was updated successfully, but these errors were encountered:
Since #56 it is possible to provide a sort of compatibility indication server side, but there is no client side preferred version possible.
We're looking into migrating to newer SpaceAPI versions but our hackerspace makes heavily use of the
null
/undefined
spacestate on the backend where it determines that aftern
minutes, there is no certain state (internet loss, power failure, building torn down).We also have multiple implementations of several (embedded) clients that reflect the v.013 state, so upgrading to the future v0.15 would most likely break those implementations (of which one is built into a car dashboard).
What would your suggestion be for a client to indicate support for newer versions?
Can these suggestions be documented as well?
In my opinion there are a couple of ways to go about:
https://ackspace.nl/spaceAPI/?api_compatibility=13,14,15
(simple, but might not work for all implementations)X-API-Compatibility:
(not recommended since customX-
prefixes are deprecated since 2012Accept
header like described in RFC7231 section 5.3.2(fairly complex) for example, prefer version 15 but accept version 14 as well:Accept: application/json;api=14;q=0.1, application/json;api=15
API endpoints might default to their liking but still provide forward compatibility while clients can specify which version they actually want.
I know this could be regarded as an edge case, but it might assist in migrating to future versions really well where a hackerspace wants to provide the latest and greatest while still pleasing the dozens of IOT devices that might be difficult to upgrade.
The text was updated successfully, but these errors were encountered: