Hi Martin,
Thanks for the response.
Of course, what you've suggested will work, but perhaps I didn't explain
myself properly.
I just spent some time trying to write an example of what we want to do,
but instead I'll present a specific example of what would have been nice.
Say we have a a list of filter parameters, all starting with the word
'filter' (filterYear, filterState, filterAge...), it would have been nice
if there was a simple way to get all filter* parameters.
The more I type, the more I understand that the solution is obvious and
relates to your suggestion.
I guess we'll play around a little with it and perhaps get an elegant
solution.
Thanks again,
Ron
On Wed, May 9, 2012 at 5:21 PM, Martin Matula <martin.matula_at_oracle.com>wrote:
> Hi Ron,
> Query parameters should still work well unless I am missing something.
> Each query param may have several values (which you can use to implement
> multi-options) and you don't have to make it part of method signatures -
> you can retrieve all query parameters as a MultivaluedMap from UriInfo that
> you can inject using @Context annotation into your resources. You can even
> use Jersey ContainerRequest/ResponseFilters for processing these parameters
> to avoid repeating the same code in each resource class.
> Martin
>
>
> On 5/8/12 11:18 PM, Ron wrote:
>
> Hi everyone,
>
> We have a new use-case in our application that I was hoping to hear some
> suggestions from other developers.
>
> Assume a list operation where you can add filters to affect the content of
> the list.
> For those of you with a LinkedIn account, run the following URL, for
> example:
>
>
> http://www.linkedin.com/search/fpsearch?type=people&keywords=sharon&pplSearchOrigin=GLHD
>
> This gives you a list of people with the name 'Sharon'. On the left side,
> there's a nice long list of filters. We're looking to implement some
> similar functionality.
>
> There are three types of filters:
> 1. Boolean - true/false.
> 2. Multi-options - one or more values of a given list.
> 3. Range - dates, numbers and so on.
>
> The API call itself has additional parameters such a search string, paging
> support and more (just to emphasize that there's more than just the filters
> as parameters).
> Since we try to adhere to the *basic* REST guidelines, since this is a
> list operation the HTTP method used is GET (in other words, no body).
> Another point to keep in mind is that we have multiple list API calls for
> different data types, where some filters are the same and some are unique
> to the specific data type. The number of filters can be around 20.
>
> We're looking for a clean solution that will hopefully give us the
> following results:
> 1. Create a clear API call, easy for our clients to implement.
> 2. Create an API call that creates a reasonable method signature
> (hopefully, one that won't take half a page due to the number of filters).
> 3. Limit the usage of only the relevant filters in a given list call.
> 4. Hopefully require us little manual parsing to some sort of a filter
> object.
> 5. Be easily documented by automatic documentation tools such as Enunciate
> or Swagger.
> 6. Easy to maintain in case of adding or removing a filter from the list.
>
> We thought of using the @MatrixParam but that doesn't solve all the
> issues, especially #3 (of course we can manually filter the filters - but
> that may be cumbersome). I'd love to hear additional ideas and suggestions
> that will hopefully comply to as many of the requirements we have as
> possible.
>
> Thanks,
> Ron
>
>
>