Refactor REST API for filters

[Brian Lewis]

Collections are currently returned in a non-standard way, via POST to end point <entity>/collection/filter. The filter arguments are in the request body.

It would be more compliant with normal REST practice to to use GET <entity>?<filterArgs>

So currently in fiddler we see this:

And in the Fiddler Inspector, you can see the JSON body:

‌

Changing as proposed we get calls like this:

But suppressing some default values before sending (reinstating them on the server) gives a cleaner presentation for debugging:

More generally, the collection/filter routes are established with “rule-based routing” which is superceded these days with “attribute based routing” which is a lot easier to manage. We should probably eliminate all these rule based routes at some point.

(see in app_start/routing.config)

‌

@Ghislain Hachey your call if you want me to proceed with this refactoring, which has come to my attention as deeper refactoring related to #795

‌

[Brian Lewis]

A further aspect of this is that the standard route can be invoked with restangular getList() method, rather than customPOST() method. this means restangular understands intrinsically that the result is a collection of records; currently we have a little more work to do on the client to get that to happen ( specifically implementing onElementRestangularized callback ).

‌

So - altogether a bit cleaner….

[Ghislain Hachey]

@Brian Lewis I’m all for a cleaner better REST API. However, doing so must be done with care as the API is now being cunsumed by other applications which we do not want to break. I suggested to version to REST API a while ago keeping older versions around giving time for others to adopt the newer API.

[Brian Lewis]

@Ghislain Hachey following request from Omega-R: I have the code from which the above screen dumps were produced in a side-branch - it would not take long to incorporate that - leaving the existing “legacy” [Post] access as well. Currently implemented for schools, but could do this initially for:

• schools
• teachers
• students
• special-ed
• ???

Maybe better to get this out of the way so Omega-R are working to the new API model?

[Brian Lewis]

see related #911

[Brian Lewis]

task(api): add standard GET endpoints for reading collections, with filter in the Uri

Resolves #821 #911

→ <<cset 8c9a28710f2b>>

[Brian Lewis]

@Ghislain Hachey some notes on this commit:

• all controllers that had a filterpaged endpoint collection/filter with Post now have GET as described. The filter object is now in the query string.
• The valid parameters for the query string are the properties of xxxFilter in Pineapplies.Data/models
• Defaults of values not supplied are provided by the server - these are set in the xxxFilter object
• Typically these defaults are PageNo=1, PageSize=50, ColumnSet=0 SortDirection='asc' SortColumn=<primary key>
• If the user wants all records, not just the first page, they should pass PageSize=0`
• query string parameters are not case-sensitive
• The Pineapples.Client has NOT been changed to use these new endpoints. (To Do?) The main intention was to get this simpler api available for Omega-R before they start to do anything with it.

‌

Consumers of these new APIs will still need to pass the Authorization header with the bearer. We could look at this - it is possible to set up Web Api to get the bearer token from the query string ( in fact, we do this when retrieving images that are the source of image tags) .

‌

‌