Question #1547

API: API Evolution

Added by Bernhard Koschiček-Krombholz 2 months ago. Updated 3 days ago.

Target version:
Start date:
Estimated time:


I have read about API evolution. It is not good practice to user version numbers, either in URI nor in HTTP Headers. The best design would be to only add things and not delete anything unless it is absolutely necessary. Endpoints and json objects should be marks with a deprecation note to tell the clients that this resource is no longer up-to-date. This should give the clients time to adjust their applications. This is also supported since OpenAPI 3.0 and since 2018 for json.

This in mind I like to discuss the possiblity to remove the version part of the URL. So /api/0.2/ will be only /api/.

Before this could happen, we need to work together, to make the API understandable and easy to use.

Related issues

Precedes Question #1549: API: deprecation of node_entities and node_entities_allAssigned2021-07-15Actions



Updated by Bernhard Koschiček-Krombholz 2 months ago

If the API should be easily understandable, it would be best when one can form sentences. Like, we declare our definitions and variables in the code. So we look into some like:


One thing is always repeating itself:_get_, but it would be better understandable.

Another possibility could, that we sort the endpoints, like we did in the documentation on swagger hub.


The advantage of this approach is, that the client knows from the path, what the endpoint will provide and how it will look like.


Updated by Bernhard Koschiček-Krombholz 2 months ago

  • Precedes Question #1549: API: deprecation of node_entities and node_entities_all added

Updated by Alexander Watzinger 3 days ago

  • Status changed from New to Assigned

Also available in: Atom PDF