Resource-Oriented WFS: Filters
Update: I made the example a little more clear by pulling the filter out of the wfs:Query.
In a previous post, I wrote that a more RESTful WFS should never accept POST as the HTTP method for a query. Well then, what to do about huge filters? IE limits your GET URI to 2K characters, and Apache will handle only up to 8K. A WFS filter containing literal geometries (like 1:250K boundaries of Norway -- potentially megabytes of fjords) could be many times larger than these limits. So, POST them, although it would be a shame to have to send the filters again for another request?
No. Posting a query destroys the uniform interface, and should only be done if there is no other option. In this case, there is another option, and a fine one: implement filter resources subordinate to feature type resources. The filtered type could then be accessed in the same manner as the feature type itself. The URI:
/places
is a feature type, and:
/places/filters/asdf
would be a subordinate filtered type. You'll recognize that this approach is not very different in concept from a Technorati watch list or a Google custom search engine.
Comments
Re: Resource-Oriented WFS: Filters
Author: Bill Thorp
Its nice to see you talking about this. How would you reference this filter? Unfortunately, referencing a URI from a query string has a logical fault (fitting 2k+ in 2k). Your post on GML+XLINK rings a strange bell; but its not REST.Re: Resource-Oriented WFS: Filters
Author: Chris Tweedie
Neat idea Sean. I'm a bit confused why a RESTful WFS services should never accept POST queries, but then your solution still involves POSTing the query template anyway? Would you envisage users being able to create filter templates with dynamic content? eg. Using your example, define a generic school query and define the literal as a var, $type$ then referece the created filter, http://gis.example.com/places/filters/21f10d70b724f5215cb183d96f27053e?type=High School% Please forgive my poor REST principles if i am going against the grain :) I could see something like this as being very powerful indeed.Re: Resource-Oriented WFS: Filters
Author: Keyur
Sean, This approach indirectly helps circumvent the browser cross-domain problem for mashup development as well: POST large datasets (such as large geometries / filters) to the origin server. This creates a new resource and returns a URI to the posted data. Now you can issue a query (a GET) to a server on another domain (with dynamic script tags) by GETing the data from the resource you just created. One caveat is that certain web servers' security policy might prohibit them from accessing external URLs. Not sure what approach would help in this scenario - proxy servers may be? Cheers.Re: Resource-Oriented WFS: Filters
Author: Sean
Bill, I don't imagine that these filters have any use other than in the context of their "parent" feature type. If you want to use a particular feature or geometry in your filter (referenced by URI) instead of a literal value, by all means do so.Re: Resource-Oriented WFS: Filters
Author: Sean
Chris, I tried to explain in my previous article why POST is not to be used for queries, but maybe I wasn't clear enough. The HTTP spec states that POST is to be used to submit data. Period. In the context of a feature query, the filter is not data, it is part of the request scoping. However, in the context of creating a new filter resource using the filter factory, the XML-encoded filter *is* data. In HTTP REST you use GET to read only, and POST to write only. Why? Interoperability. The templates are an interesting idea. I've been thinking more about desktop WFS clients with powerful forms and wizards for creating arbitrary filters, and they wouldn't need or use such templates. For other clients, I think you want a simpler API. Instead of expose a resource to be accessed like Keyur: I hadn't considered the proxying implications at all. Interesting.