When a query request is made, resgate have no way to determine if two non-identical query strings may represent the same data, and will have to fetch the data for both queries as well as responding twice to each query event on the resource.
Example of different queries for the same resource
The following resource IDs may represent the same data
bookService.books?genre=scifi&year=2017&page=1bookService.books?year=2017&genre=scifi&page=01bookService.books?year=2017&genre=scifi&nonsense=param&page=1
Suggested solution
A new property, query, should be added to the response of a get request. The property should contain the normalized version of the query. Normalization is defined by the service, but may be sorting the fields, removing fields not part of the query, and normalizing the field values.
If no fields are used by the resource, the property should be omitted indicating that the response is not a query resource, but the same as requesting the resource without query. This will make it easier for non-query resources as they don't have to bother if the request has a query field or not, while currently they have to specifically check if the query property on get requests, sending a system.notFound response if a query exists.
Issue
When a query request is made, resgate have no way to determine if two non-identical query strings may represent the same data, and will have to fetch the data for both queries as well as responding twice to each query event on the resource.
Example of different queries for the same resource
The following resource IDs may represent the same data
bookService.books?genre=scifi&year=2017&page=1
bookService.books?year=2017&genre=scifi&page=01
bookService.books?year=2017&genre=scifi&nonsense=param&page=1
Suggested solution
A new property,
query
, should be added to the response of a get request. The property should contain the normalized version of the query. Normalization is defined by the service, but may be sorting the fields, removing fields not part of the query, and normalizing the field values.If no fields are used by the resource, the property should be omitted indicating that the response is not a query resource, but the same as requesting the resource without query. This will make it easier for non-query resources as they don't have to bother if the request has a query field or not, while currently they have to specifically check if the query property on get requests, sending a
system.notFound
response if a query exists.Example of query normalization
Request:
get.bookService.books
Payload:Response: