mozilla
nested user info in author attribute on /projects JSON response
wondering why we replaced user_id with an author attribute that nests the entirety of a user object in the JSON response for a project.
this is a problem better solved by the include design pattern: http://jsonapi.org/format/#fetching-includes. this pattern is a single request, but doesn't break the data structures, preserves the relation.
@cadecairos mentioned that this design is a result of a request from the client team. an API should really be client agnostic. if the client requires something specific, one should write a middleware to do that work.
the current structure of the API makes it very hard to write additional consuming clients.
This was probably to reduce the number of HTTP requests necessary to build a view. That's generally the reason for adding metadata to a route anyway.
I think we are going to start needing some kind of middleware between the service and app.
Another case that's already come up is needing to nullify link destinations for buttons in a project when a page is deleted. This is the kind of cumbersome data modeling that doesn't really belong on a low level API or on the client (where I started to implement it, but it's pretty gross IMO).
i def think middleware is a good option in a usecase that requires it. i'm not yet completely convinced that we are in that situation..
either way: did you take a look at how jsonapi.org solves the need to reduce http requests? it's non-destructive and generic.
@gvn which part is the CC for? general "we should not rewrite the model output to suit the client, just have the client rewrite what it needs based on what the API claims it will send to anyone asking" (which I agree with) or the use case cited (which feels like a separate issue since it deals with "how do we efficiently get things to happen")
CC was just bringing y'all into this conversation, not for anything in particular. I think middleware is something we all should discuss.