Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark preferred version of API #219

Closed
IvanGoncharov opened this issue Apr 1, 2016 · 3 comments
Closed

Mark preferred version of API #219

IvanGoncharov opened this issue Apr 1, 2016 · 3 comments
Assignees

Comments

@IvanGoncharov
Copy link
Contributor

Some APIs have multiple swagger files documenting different versions.
In my service, by default show preferred version of API.
Could you please mark preferred version somehow?
For example, Git support symlinks, so you can make $api/preferred/ point to dir with preferred version.

@devigned
Copy link
Member

devigned commented Apr 1, 2016

Hmm... I guess we could do this, but I'm not sure we should think about versions this way. All versions that are not preview should be equally good for customers to consume. There is no preference other than feature set.

We could provide guidance to point toward the latest, or simply have the convention rather than having to keep updating the symlink when a new version is available.

@IvanGoncharov
Copy link
Contributor Author

@devigned

All versions that are not preview should be equally good for customers to consume.

Yes, but imagine person see your API for the first time without any previous experience with it.
I think, to explain it litter bit better I need to provide some background.

I working on catalog of OpenAPI specs for public APIs.
Some 3rd-party tools/services access it through my own API.
Have sample site to show simplest possible UI, I think this screenshot illustrate my current strategy:
selection_030
So user always presented with the latest version but it still possible to choose previous ones.

We could provide guidance to point toward the latest, or simply have the convention rather than having to keep updating the symlink when a new version is available.

Alternative you can mark it inside spec itself.
In my catalog I currently use x-preferred with boolean as the value.
I borrow this semantic from Google Discovery, see this

@kirthik kirthik added the P1 label Feb 10, 2017
blueww pushed a commit to blueww/azure-rest-api-specs that referenced this issue Dec 8, 2017
* drastically simplified the subscription creation by removing the concept of billing context and changing offer to an enum

* responded to review feedback

* fixed spelling errors
@salameer
Copy link
Member

salameer commented Oct 8, 2018

Hi @IvanGoncharov

The API documented inside the Stable folder version are the ones that customer would write stable code on, "Preffered" would be a bit subjective depending on what the customers are looking for. Some prefer latest stable other prefer to lock on a specific version.

Ofcourse the more recent version that you adopt the more goodness of features you get :)

Thanks

Closing and please re-open if you have other questions

Thanks

Samer

@salameer salameer closed this as completed Oct 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants