Seaside-REST with variable query fields

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside-REST with variable query fields

Esteban A. Maringolo
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?



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Seaside-REST with variable query fields

Philippe Marschall
On Wed, Dec 3, 2014 at 6:30 PM, Esteban A. Maringolo
<[hidden email]> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Seaside-REST with variable query fields

Esteban A. Maringolo
I looked into the implementation before sending the email and also found I'd need to modify WAComplexRoute to match the required path patterns. Didn't realize I'd need to modify the WARouteContainer too, with your explanation it's clear why.

I'll check what you suggested during the weekend to see if it works.

Thank you!


El Wed Dec 03 2014 at 7:03:44 PM, Philippe Marschall <[hidden email]> escribió:
On Wed, Dec 3, 2014 at 6:30 PM, Esteban A. Maringolo
<[hidden email]> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside