LoopBack 4 API Versioning

[PareshNeosoft]

Hello,

I'm looking for some guidance on how one could implement "standard" REST API versioning (ex: /api/v1/{model} /api/v2/{model}) within loopback 4.
The models may have different structures but would have the same backing records in the database. In our instance, the database will be Mongo.

Most implementations in express seem to route to endpoints based on the /v{n} with each version implementing its own endpoints. Later version methods that do not alter functionality call the earlier version of the method to avoid code duplication.

Since loopback in building routes based on models, what is the suggested method for loopback? Has anyone implemented API versioning in loopback 4?

[marioestradarosa]

@PareshNeosoft you should follow standards OR most common used strategies. The models just reflect the object you are trying to reach but loopback4 is not only meant to work with models you can create any type of controller with any type of end points.

So if I have car model it is expressed by /cars with http verbs post, get, put, patch .

Notice that I usually enable the versioning from the ingress/load balancer/nginx etc. to point to the appropriate micro service or application.

car model

 { id: number, model: number }

And then you roll out a new version for this model that will not only incremented the number of properties but also behavior (business logic)

new car model

 { id: number, model: number, price: number, description: string }

When to use a new / api version number?

Scenario 1: We released a new version BUT our customers can still get benefit from previous version or we are having a partial deployment to production (Blue/Green)

In this scenario /v1/cars and /v2/cars would eventually live as part of your cluster with probably different ports and routed based on the versioning flag.

Scenario 2: We need to force our customers to use the new API, since our business logic has changed also

In this scenario, no need to rollout a new API version, since customers are force to use the current one, and they are aware of the changes to implement in their client code.

Disclaimer: This is my personal opinion only.

[napondo]

@marioestradarosa
Much appreciated.
Loopback 3 had a stubbish guide on the technical implementation of versioning that can be found here. Where would I find similar docs on Loopback 4? I am particularly interested in the instance where I need to have a /v1 and /v2