How does the APP API maintain several versions of some ideas?

1, the first form: The API version number is placed in the URL path

HTTPS://api.example.com/v1/user/idhttps://api.example.com/v2/user/idhttps: // api.example.com/v3/user/id

2, the second form: The API version number is placed in the URL parameter

HTTPS://Api.example.com/user/id?version=v1& . HTTPS://Api.example.com/user/id?version=v2& . HTTPS://Api.example.com/user/id?version=v3& .

This is simple and easy to understand, but in each of your interface logic you need to write a version of the code. Like what:

if (version=='v1') {...} Else if (version=='v2') {...}

This kind of code seems to feel uncomfortable. and will maintain a lot of if-else, will be more and more long.

3. The third form: The API version number is placed in the header of the request
When the client makes the request, it adds the Api-version field in the HTTP head to identify which interface is requested:

" Api-version:v1 " " Api-version:v2 "

There is a little bit more to do with this unification, but then the interface logic will be better. Get the interface version at the entrance, and then distribute the request to the corresponding version of the interface processor.

4, the fourth form: The API version number is placed in the two-level domain name
Different versions use different domain names, for example:

V1.api.xxx.comv2.api.xxx.com

The way the domain name can be used in the following two ways:
1, different versions of the API deployed to different applications (even can be deployed to different servers), independent of each other, the benefit is that the deployment process will not affect the use of other versions of the API, and can reduce the burden on a single server.

2, deployed in one application, but the same as the third, at the interface entrance is distributed to different versions of the interface processor for processing. The benefit is that the same functionality can be reused directly from one version to another.

To summarize:
Personal comparisons tend to be the first (xxx.com/v1/, xxx.com/v2/):

The number and functionality of the interface may increase over the lifetime of the product, but for an interface, there is no frequent change (modify the interface's input and output conventions), and an increased interface has no effect on the old interface. There will be no need to upgrade the interface (your old app is just the old interface that existed, the new added interface has no effect on it).

If your interface has changed to the point of today's V1, tomorrow V2, and the day after V3, consider whether the need for your product is accurate enough at first (estimating the interface documentation that needs to be maintained is also a headache).

Different versions of the interface are independent of each other to a certain extent limiting you, so you will not casually V1, V2, v3. (When you use a new domain name every day, you will not naturally reflect on the change is too frequent).

Interface version information can be directly reflected in the URL, clear and easy to do interface debugging (yes, give me a chrome is enough).

Different versions of API applications (or interface processors) are independent of each other, which conforms to the low-coupling principle of software engineering.

There is no very elegant design, can only consider the long-term writing, interface code to write more extensibility. The app is not the same as the website, even if you send the new version or there is a high chance that users do not buy the update. So it is best to design the interface at the beginning of the time to think about the long-term, API URL can not be arbitrarily moved,

So the design of the core business API can only be considered relatively clear, some things just start not to do but the recent version to do the pre-leave a good entry, code to write the scalability of a little more convenient for later compatibility, the database can also first reserved good field.

The maintenance of the version interface is considered catastrophic by the individual. Different versions of the business logic, need to operate the latest version of the data structure, but also maintain the version of the document, each version of the automated testing or manual testing.

So personally think the better thing is, in the beginning of the design, query the interface of the class, as far as possible to use passive data to provide a stateless interface, the format should be possible to use the object (do not use two-dimensional collection), such an interface for the extension of the field is very convenient, but also easy to do backwards compatibility.

Manipulate the interface of the class, as far as possible to separate resources, such as modify user information, and modify the user profile picture information or modify the user position information, such an interface, as far as possible to use independent resources.

There is no way to fully upgrade the interface.

If possible, maintain the original business, the original interface works normally.

Then build a completely new set of isolated interfaces.

Finally do the next version using monitoring. When you observe that all users are using the new version of the client, and keep it for a while. Abandon the maintenance of the old version, and then drop the old version of the resources. Of course, you can also use force updates when last resort.

How does the APP API maintain several versions of some ideas?