Query Parameter Services

[maurei]

Closes #562

This PR contains a rework of the internal handling of query parameters. Apart from refactoring, cleaning up and adding unit tests, it contains the following major changes:

• Decoupled query parameter services
• Migrated responsibilities
• Easier extensibility

These are now discussed below

Decoupled query parameter services

Every supported url query parameter now has an associated dedicated service for parsing it and internally exposing it.

Query Parameter Service	Occurence in URL	Domain
IFilterService	?filter[article.title]=title	filtering the resultset
IIncludeService	?include=article.author	including related data
IPageService	?page[size]=10&page[number]=3	pagination of the resultset
ISortService	?sort=-title	sorting the resultset
ISparseFieldsService	?fields[article]=title,summary	sparse field selection
IOmitDefaultService	?omitDefault=true	omitting default values from the serialization result, eg guid-value": "00000000-0000-0000-0000-000000000000"
IOmitNullService	?omitNull=false	omitting null values from the serialization result

Throughout the framework, each of these services are now injected only in the places where they are needed. For example: the serialization layer does no longer have access to the filter, sort, page queries.

Migrated responsibilities

As mentioned in the previous part, these dedicated services are responsible for parsing and internally exposing the query parameter. This implies that the following migrations of responsibilities have been introduced

• the previously existing IQueryParser service is no longer responsible for parsing the url query parameters. The parsing logic for each query has been moved to it's dedicated service (through the implementation of the IQueryParameter interface).
  • eg only the IFilterService should know how to parse a filter[X]=Y query string
• IQueryParser is now IQueryParameterDiscovery which is only responsible for discovering the registered query parameter services and providing them with the appropriate part of the URL query string
  • eg it calles the IFilterServices.Parse method with the filter[X]=Y part of the query string.
• the repository layer used to be responsible for validating parsed values of query parameters. This responsibility too has been moved to the dedicated query parameter service.
  • eg the Include method used to be called with a list of strings (like "article.author.invalid-relationship"), and this list would then be validated and converted into the RelationshipsAttribute that is actually reflected by that relationship chian. This type of validation now happens directly upon parsing the query parameters in the middleware

Better extensibility

To register a custom query parameter, all one needs to do is register an implementation of IQueryParameterService. See the Query Parameter Services wiki.

[maurei]

Consistency and best practise: use singular words for enums

[maurei]

These are fully deprecated in their old forms

[maurei]

This is not an entirely new class, merely a refactor of the previously RelatedAttrFilterQuery and AttributeAttrFilterQuery

[maurei]

Removed things from former request manager that are no longer referenced

[maurei]

Removed this as it is incomplete and untested.

[wisepotato]

We should consider adding Query in each of the service names.

[wisepotato]

wiki is clear however it looks like i can only insert one extra paramservice, is this true? how do i add two? would i have:

services.AddScoped<IQueryParameterService, TeapotService>();
services.AddScoped<IQueryParameterService, OtherTeaPotService>();

?