René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Support conditional link serialization format","articleBody":"This would be a really killer feature for my project. I have some ember routes that fetch a decently complex graph of data, and there's really no good way to inform the server that this particular route needs to side-load deeply, while maintaining the ability to return sparse results at other times (say, when loading a list).\n\nFor a simple example. I have a resource called `Organization`, which has many `Notes`. Notes have a `User` that entered the note. When I load an organization detail record, I want to load all the notes for that organization, as well the user that entered each note, preferably all in a single AJAX request. However if I am on a route where I need to fetch a list of Organizations, I only want to serialize an href to fetch the related records. As far as I can tell, this kind of conditional link formatting isn't yet possible. [The spec](http://jsonapi.org/format/#fetching-includes) has a solution for this, by allowing the client to specify resource paths to include.\n\nI'm happy to put in the legwork toward implementing this feature, but I want to make sure I get the architecture right. The first step is to add a parameter to the Get methods on ApiController\u003cT\u003e to gain access to the `include` query param. After that I'm not sure, I guess we have to change the IMaterializer interface somehow to allow the ApiController to tell the provider what to include. Then here comes the hard part: How do we tell the formatter to override its own strategy for resource linking behavior, and instead use what the client sent? Remember, MediaTypeFormatter does not have access to the request context.\n\nTwo potential solutions occur to me:\n1. Make the formatter not be in charge of deciding what relationships to serialize at all. We add another action filter that runs after our other filters (filter, sort, enumerate). This filter would consult the IModelManager, and then modify the object content to return an ExpandoObject, and all the formatter has to do is serialize that to JSON.\n2. Still add another action filter, but instead of using the model manager, have it wrap the content in some sort of object that contains hints for the formatter to tell it what relationships to serialize. The formatter would be changed to handle this new object if it sees it, and fall back to the existing behavior if it is passed something else.\n#2 is less of a drastic change and I think I prefer it, just wanted to get your thoughts. Am I missing something obvious?\n","author":{"url":"https://github.com/csantero","@type":"Person","name":"csantero"},"datePublished":"2015-01-26T22:39:48.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/27/JSONAPI.NET/issues/27"}