Actually use API versioning

This is a request due a problem we recently had with a customer.
We implement a custom mechanism for Zammad which opens/closes tickets (etc.).
This worked fine until the recent API changes in 6.5.
These changes were announced and (roughly) documented, so I am not trying to assign blame here.

But. The API url contains a v1 in there which led me to the assumption, that led me to the assumption that breaking changes would only be implemented in a v2 (or higher) and that v1 would be kept stable. That is of course not written anywhere, just my assumption, but I thought that would be the pattern. Why else put a version in there?

I think it would be a great feature if some ground rules about changing interfaces could be build, this would improve Zammad in a meta way.
People will, of course, always complain about changes, but it still is better, if they can be communicated explicitely and reliably.

I hope I am not stepping on anybodys toe here and if so I would like to ask for forgiveness.

Have a nice day :slight_smile:

2 Likes

The idea is at some point to really use this API-Version, but currently this is not the case. After we finished our rewrite for the Desktop-View, which will use GraphQL the idea is to re-think the current REST-API, because it’s then mainly used for direct API communication and no longer from frontend perspective.

1 Like

Hi @dominikklein, thank you for the response :slight_smile: