For a new microservice we were designing, I recently had a design discussion with a team member on creating REST endpoints for a new entity. This discussion went on for almost 3 hours, most of the time was spent on why to have two endpoints for getting this resource, one is a POST using a graphQL-like query and another one is a GET using unique ID. I said, the client-side use case is different, one is a dashboard where search results need to be shown based on multiple fields and the unique ID won't be available there because it is a system generated value, second one will be used when the unique ID is present in the client as a result of previous search result. Their responses will be similar, first returns a list of entities, second returns a single entity of the same structure.

Then came the next argument: if both APIs are returning same response, why do we need two different requests ?

It was like saying, because 5+6=11, any sum of two numbers resulting in 11 should always use 5 & 6.

Are people so frustrated of working remotely all the time that they come with such weird arguments ?

  • 0
    I would hope whatever tech they're using was capable of easily discriminating those endpoints.

    "Get api/entity/{Id}" is an altogether different route from "get api/entity?filter=..."
Add Comment