CODEWITHSUNDEEP
restapi-versioning
Harpreet
Harpreet

Reputation: 1607

Best approach for api versioning while adding new business validation

I have a project to maintain the user and his/her project allocation records. The project exposes REST APIs to support user/project CRUD operations.
The REST endpoints are designed to support backward compatibility using REST API versioning so that any new changes in the REST API should not affect the existing consumer of that API.

I have the below use case where I need suggestions for the best approach:
At first, the business requirement was that a user can be deleted irrespective of his/her allocation to some project and hence the REST API to delete the user was created with version v1 to support this.
But then there was a change in the requirement that a user cannot be deleted if he/she is allocated some project.

This is a change in business validation. Should I create a new version(v2) of user DELETE REST API to support this business validation or I should add this business validation to the existing version(v1) of user DELETE REST API?

My viewpoint:
If I will expose two versions of the user DELETE REST API then the database can have records with deleted users with as well as without project

Upvotes: 0

Views: 319

Answers (1)

Chris Martinez
Chris Martinez

Reputation: 4388

I would argue that this is more of an implementation detail of the backing store. In all likelihood, the storage mechanism for both is almost certainly the same.

I would not change the DELETE API nor version it because the contract is 100% the same over the wire. A client has no idea how it's implemented behind the scenes; they're not supposed to anyway. The implementation needs to change such that a DELETE always results in a soft delete after some point in time (e.g. when you publish the new version). If you version DELETE you also open things up where clients can do things you don't intend; for example, triggering a real deletion by using a specific version of the API.

The thing that needs to change is how the older APIs deal with all of the other supported methods such as GET, POST, PATCH, and so on. The older APIs should yield 404 for a soft deleted resource (implying that DELETE was permanent). POST is probably the most unusual case. This could return 409, but that implies the resource exists or it could result in an update that also undeletes the existing resource. This API would likely even continue to return 201, implying the resource was created when it was really just updated in storage.

Remember that Representational State Transfer is just a representation of your business logic. Keep the APIs the same (and thus clients from breaking) and adjust the implementation to adapt to new rules. The DELETE API is unchanged (and usually version-neutral). Clients don't know what the man behind the curtain is doing. If things continue to behave the same over the wire, clients are none the wiser.

I hope that helps.

Upvotes: 1

Related Questions