3

Context

There is a back end and a front end team.

Back end exposes an endpoint to the front end app:

PATCH car/{carID}/tire

Problem

I want to update the aforementioned PATCH request functionality which will change the request's body .

Solution

There are two options:

  • Change the current endpoint and ask the front end team to update the payload on the request's body.
  • Create a new endpoint car/{engineID}/v2/tire , so the front end team can switch to this version when they see fit.

Question

I prefer the second approach, as it allows the two teams to work asynchronously . The short coming here is that every time I will need to update this endpoint I will need to expose a newer version ??

In which scenarios should I follow the first approach, which actually breaks the current system ? Does this violates the open-closed principle ? Does the open-closed principle apply here ? Should I follow this principle in this scenario ? Is there another alternative to the two aforementioned methods ? Is there a design flaw that resulted in this scenario ?

3
  • I'd second that approach. Major changes, such as the payload, the response - basically everything that results in being incompatible should be separated. Minor changes in the backend that don't require any changes in the frontend shouldn't, though. But that's not the case here.
    – devsmn
    Oct 21, 2020 at 14:16
  • I had this question as well ! So minor changes just update , major expose newer version ? Oct 21, 2020 at 14:19
  • I'd specify the new version to 'major changes that also require the consumer (frontend) to do something'.
    – devsmn
    Oct 21, 2020 at 14:22

1 Answer 1

4

Breaking changes vs non breaking changes

Your endpoint and the resources exchanged over it basically define a contract between the back-end and the front-end.

You can have some changes done to the endpoint without breaking the contract and affecting your front-end. For example, you can have new data added to the response but without removing the already existing data, your endpoint might accept optional parameters, etc. These kind of changes don't affect your front-end because it's extra stuff to what is already known and expected.

Breaking changes will break the contract, so the front-end will need to change. Breaking changes include, for example, changing property names or their types, adding mandatory parameters for the endpoint, etc.

What approach you eventually use depends on what kind of changes you did. And this is a large topic about API versioning, and can be done any number of ways, like for example.

The way to choose an approach is to talk with your front-end team. Ask them how they prefer to be notified of changes and how they want to implement them. Then together decide what works best for everyone involved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.