[Seaside] Seaside-REST with variable query fields

[Philippe Marschall]

On Wed, Dec 3, 2014 at 6:30 PM, Esteban A. Maringolo
<emaringolo at gmail.com> wrote:
> I'm trying to implement a RestfulHandler to handle search based on a
> variable set of query fields.
>
> E.g.:
> <path: '/api/orders/search?field1=..&field2=...'>
>
> The problem is I don't know the list of fields beforehand, maybe in one
> request I'll get both field1 & field2, but in others just field1, and/or
> fieldN.
>
> Given the fact that the methods need to have as many parameters as the
> predefined parameters in the path pragma, I couldn't find a way to define a
> path to match both a request with or without query fields.
>
> something like:
> <path: '/api/orders/search[?queryString]'>
>
> Is there a way to this?

As long as you don't need/want queryString injection and are fine with
a lookup of the query fields through the request context (IMHO
queryString injection isn't that useful anyways since it would be
unparsed) it should be possible to update the matching engine to
ignore additional parameter matches if the scoring engine is updated
accordingly. Here's what you need to change:
- WAComplexRoute >> #matchesParameters:, additional parameters should
be ignored but all parameters in the route have to be present in the
dictionary. Basically remove the size check.
- WARouteContainer >> #initializeWith:, the sorted collection block
needs to be updated to first sort by path priority and then by
parameter priority. This has to work with both WAComplexRoute and
WASimpleRoute. A simple fix would be to split #priority into
#pathPriority (current #priority) and #parameterPriority (number of
parameter matches, 0 for WASimpleRoute) and then first compare by
#pathPriority and then by #parameterPriority. You may want to remove
#priority to make sure you catch all the senders that need to be
updated.
- You need to make sure that you get an error in case of conflicts, eg
in case of

<path: '/api/orders/search?field1=..'>
<path: '/api/orders/search?field2=...'>

and a query string of

/api/orders/search?field1=..&field2=...

an error should be signaled. If you're lucky that's already the case
but likely you'll have to update
#compareByPathThenContentType:thenByAccept: to take #pathPriority and
#parameterPriority into consideration as well.

Can you try this you and see if it does what you need?

Cheers
Philippe