Is your feature request related to a problem? Please describe.
It seems the swagger API is always version 1.0. Also, it points to the trackhub dev page.
https://app.swaggerhub.com/apis-docs/dtitov/TrackFind
Describe the solution you'd like
I think we should have two seperate documentation pages, one for dev and one for prod, automatically deployed (I think this is already true). The version of TrackFind should be clearly stated. It might be a point to have a separate version of the REST api itself, but in that case, this must be handled in a way the version is updated when changed, and that it is clear which versions of TrackFind itself this corresponds to. In any case, there should be a release log or other documentation of the changes, so that consumers can find clear information on API changes.
Currently the URL contains "api/v1", which is a choice that makes sense to me for two possible reasons. Either you are intending to provide more than one API version simultaneously, so that existing consumers will not break even if the API contains breaking changes, in which case it is a good idea. The alternative is that you intend consumer functionality to break if the version is increased, which I don't think is a good idea, as they might be using parts of the API that have not changed. A third possibility is of course that the consequences have not been addressed. I anyway don't really know what is the typical solution for such issues.
Is your feature request related to a problem? Please describe.
It seems the swagger API is always version 1.0. Also, it points to the trackhub dev page.
https://app.swaggerhub.com/apis-docs/dtitov/TrackFind
Describe the solution you'd like
I think we should have two seperate documentation pages, one for dev and one for prod, automatically deployed (I think this is already true). The version of TrackFind should be clearly stated. It might be a point to have a separate version of the REST api itself, but in that case, this must be handled in a way the version is updated when changed, and that it is clear which versions of TrackFind itself this corresponds to. In any case, there should be a release log or other documentation of the changes, so that consumers can find clear information on API changes.
Currently the URL contains "api/v1", which is a choice that makes sense to me for two possible reasons. Either you are intending to provide more than one API version simultaneously, so that existing consumers will not break even if the API contains breaking changes, in which case it is a good idea. The alternative is that you intend consumer functionality to break if the version is increased, which I don't think is a good idea, as they might be using parts of the API that have not changed. A third possibility is of course that the consequences have not been addressed. I anyway don't really know what is the typical solution for such issues.