Recommended method for changing Get IQueryable for EF document materializer

[ClintGood]

Thanks to all that put their efforts into this project.

I understand that as per the JSON API we can add filter expressions to the URL and they affect the records returned from get requests.

My use case is that I want to filter records returned, even without the query expression in the URL. To take my case as an example I have a self referential EF entity that forms a tree.

I want a request to "/things" to only return any root nodes, not all nodes in the entire tree.

To me it appears solution would be to change EntityFrameworkDocumentMaterializer.GetRecords so that it used new property in the IResourceTypeConfiguration interface and optionally included a where clause.

Would this be the way to implement this functionality or would another method be a better fit?

There was talk of changing of how configuration worked. Has there been any progress in this area or is there a vision for how this could be changed?

Any guidance on how you would envisage this functionality being implemented, or problems with my plan is appreciated and may increase any work I do in my fork being useful to the project in general.

[csantero]

@ClintGood This is something I frequently have to do in my project, and my solution was to just not use EntityFrameworkDocumentMaterializer. I typically use a custom implementation of IDocumentMaterializer for each type of resource, which makes its own IQueryable.

It's been clear to me for a while that the Materializer model is not working - or at least that it is the wrong extension point for users of the library. The framework should be the one in charge of dealing with serialization, and the user should only be responsible for telling it how to resolve the following:

1. A single resource
2. The collection of all resources of a type
3. The resource found in a to-one relationship
4. The collection of resources found in a to-many relationship

A possible configuration API for this might look like:

    configuration.RegisterResourceType<Post>()
        .ResolveSingleWith<PostsSingleResourceResolver>()
        .ResolveCollectionWith<PostsCollectionResourceResolver>()
        .ResolveToOneRelationshipWith<PostAuthorResourceResolver>(p => p.Author)
        .ResolveToManyRelationshipWith<PostCommentsResourceResolver(p => p.Comments);

...

public interface ISingleResourceResolver<TResource>
{
    Task<IQueryable<TResource>> GetQueryForSingleResource(string id, HttpRequestMessage request, CancellationToken cancellationToken);
}

public interface IResourceCollectionResolver<TResource>
{
    Task<IQueryable<TResource>> GetQueryForResourceCollection(HttpRequestMessage request, CancellationToken cancellationToken);
}

public interface IRelationshipResolver<TResource, TRelatedResource>
{
    Task<IQueryable<TRelatedResource>> GetQueryForResourceCollection(HttpRequestMessage request, CancellationToken cancellationToken);
}

public class PostsSingleResourceResolver : ISingleResourceResolver<Post> { ... }
public class PostsCollectionResourceResolver: IResourceCollectionResolver<Post> { ... }
public class PostAuthorResourceResolver: IRelationshipResolver<Post, Author> { ... }
public class PostCommentsResourceResolver: IRelationshipResolver<Post, Comment> { ... }

The methods on these "resolvers" would all return IQueryables because JSONAPI.NET would still be responsible for performing sorting, filtering, and pagination.

I haven't touched on Create/Update/Delete, but I imagine they'd use a similar API. There would also need to be a generic fallback setting so if for example you don't specify ResolveSingleWith, a default implementation will take over.

These are just some rough ideas, but I think it's the direction I'd like to see the framework head.

[spike83]

+1 I have a related problem implementing a search function which affects multiple properties. So for me the IResourceCollectionResolver<TResource> would be very helpful.