list filtering

[Max Arnold]

Hi,

Is there any example implementations of list filtering? Currently I have the following resources:

/countries/
/country/<id>/regions/
/region/<id>/cities/

Each country element in /countries/ list contains url to its regions, and each region has link to list of cities.
To document API structure, I'm forced to hardcode some country or region ID in Root Resource in order to reverse urls to
list of regions or cities.

I want to change url structure to be like this:

/countries/
/regions/
/cities/

and have optional country_id and region_id filters (as GET parameters) to limit /regions/ and /cities/ list.

What is the best way to implement discoverability of these filters in d-r-f? I'm thinking about adding support
for GET forms, custom OPTIONS or response metadata.

[Jani Tiainen]

9.5.2012 10:35, Max Arnold kirjoitti:
> Hi,
>
> Is there any example implementations of list filtering? Currently I have the following resources:
>
> /countries/
> /country/<id>/regions/
> /region/<id>/cities/
>
> Each country element in /countries/ list contains url to its regions, and each region has link to list of cities.
> To document API structure, I'm forced to hardcode some country or region ID in Root Resource in order to reverse urls to
> list of regions or cities.

That is slightly abusive approach. For example /country/<id>/regions
refers to some specific country regions. With above structures there is
no absolute way to list purely just regions or cities.

If you want to go to gray area you could assign some id, like 0 or -1 to
mean "Any country" or "Any region" resource.

> I want to change url structure to be like this:
>
> /countries/
> /regions/
> /cities/
>
> and have optional country_id and region_id filters (as GET parameters) to limit /regions/ and /cities/ list.
>
> What is the best way to implement discoverability of these filters in d-r-f? I'm thinking about adding support
> for GET forms, custom OPTIONS or response metadata.

By doing this url change you're actually going to violate REST principles.

You should have both if you need full lists:

/countries/
/countries/<id>/regions/
/regions/
/regions/<id>/cities/
/cities/

So yes, you need to define quite a load of URLs but that's the nature of
RESTful services.

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...