I just found myself in a position where I need to re-write an endpoint to deal with what in hindsight feels like an obvious mistake.
If you are ever writing an endpoint and you’re returning one type of object for one set of requests and a highly-related, but still slightly different object for another set of requests, that is a sign that you probably need to split your one endpoint into two endpoints.
In my case, both use cases are asking the endpoint for a list of the same kind of underlying widget, but they are asking for slightly different ‘snapshots’ of that underlying object.
I’ve partially de-normalized my database when it comes to this foundational (to my application) widget as a way of reducing joins, which means that depending on which view of the widget one is after, a different table is hit.
I started out thinking ‘this route gives me a list of widgets’, but now I’m realizing that I need to proceed under a ‘this route gives me this view of the widgets’ and ‘that route gives me a different view of the widgets’ which means that I always return the exact same type of object across the one route and a different (but always the same for that route) type of object for the second route.
As painful as it is to have to re-work an endpoint (and all of the associated tests), I suspect this is the better option in the long run, and will keep things from getting unnecessarily complicated down the road.