API versioning

2023-06-26T11:19:31Z

207.191.199.140:

<languages/>
{{Deprecation policies}}
This page describes the API versioning policy for the Wikimedia [[REST API|REST APIs]], which are documented at [https://en.wikipedia.org/api/rest_v1/?doc /api/rest_v1/?doc] for each wiki.

<translate>
== Global API version == 
</translate>
The global API version is part of the path.
Example: <code>/v1/</code>.
Following the principles of [http://semver.org/ semantic versioning], it is incremented when a '''stable end point''' is changed in a backwards-incompatible manner.
For the global version, we consider changes breaking if stable end points are removed, or the request structure changes in incompatible ways.
Content types are versioned using content negotiation, and do not trigger global version increments.
Since the introduction of a new major API version is a very disruptive event, we try hard to avoid breaking stable end points.

<translate>
== End point stability == 
</translate>
Each API end point is marked with a stability class: ''Stable'', ''unstable'', ''experimental'' or ''deprecated''.
Typically, API end points start out as experimental or unstable, and over time graduate to become part of the stable API.

<translate>
=== Stable === 
</translate>
Stable end points are guaranteed to not change in incompatible ways.
This means that you can be sure that the basic interface as documented by the spec will continue to work as described.

<translate>
=== Unstable === 
</translate>
End points marked as unstable can change in incompatible ways without incrementing the ''major'' API version, but they will increment minor versions.
We will reach out to users and make a concerted effort to avoid breaking existing consumers.

<translate>
=== [[Extension Matrix/experimental|Experimental]] === 
</translate>
Experimental end points can change in incompatible ways at any time, without incrementing the API version.
You are welcome to use them at your own risk.

<translate>
=== Deprecated === 
</translate>
If an end point is marked as deprecated, it means that it has not been useful to clients and will consequently be removed in the near future.
If your code is using such an end point, you should stop using it as soon as possible.
We will always make sure to provide users with alternative ways of obtaining the same information.

<translate>
== Content format stability and negotiation == 
</translate>
Changes in the structure of the returned content will be clearly indicated by a change in the profile part of the mime type:
text/html; charset=utf-8; profile="[[Specs/HTML/2.0.0|https://www.mediawiki.org/wiki/Specs/HTML/2.0.0]]"
For longer-term output format stability, you should send an <code>Accept</code> header with the mime type you expect:
Accept: text/html; charset=utf-8; profile="<nowiki>https://www.mediawiki.org/wiki/Specs/HTML/2.0.0</nowiki>"
In case of output format changes, the API will then continue to respond with the requested format (subject to semantic versioning protocol, see below), even if a newer format is available.
Support for old output formats will normally be maintained until usage drops below a low threshold.
Phased-out formats will be announced with ample warning on [[mail:mediawiki-api-announce|the API-announce list]].

<translate>
=== Background: How we interpret semver in format negotiations === 
</translate>
Our profile URLs generally end with a version number based on the [http://semver.org/ semver semantic versioning scheme].
In semantic versioning, all backwards-incompatible changes trigger an increment of the major version number (ex: 1.2.1 to 2.0.0).
As the goal of our format negotiation mechanism is to avoid breaking clients, this is what we are focusing on.
Clients are encouraged to provide the exact version they tested with, but the API will typically return the '''''latest''''' content-type that is compatible with the requested '''''major''''' version More specifically, we will return the latest minor version compatible with the requested major version, but won't make guarantees about the returned patch version for performance reasons.

The exact protocol is:

# If client-requested version is matching semver ''major'' version and has lower ''minor'' version then stored - return stored content
# If the client-requested version is semver ''major'' or ''minor'' greater then stored version - update the content
## If updated content is matching requested ''major'' version and has higher or equal ''minor'' version - return
## If updated content has lower ''major'' or ''minor'' version - return 406 error
## If updated content has higher major version - go to point 3.
# If requested version is semver ''major'' lower then stored - transform content to downgrade.

<translate>
== See also == 
</translate>
* The [[Specs|Specs page hierarchy on this wiki]] documents versioned content formats.
* See this [[Phab:T124365|RFC discussion]] as well as [[Talk:API versioning|this section of this article's talk page]] for background on how we arrived at the format versioning strategy outlined here.

[[Category:MediaWiki development{{#translation:}}]]

MediaWiki - User contributions [en]

API versioning