I get glimpses of discussion on the non-public WFS Simple/Basic email list about a RESTful makeover for the protocol. We're going to see more and more of this as the developers of all public-facing services realize that they need at least a minimal RESTful aspect. Here's what that looks like for WFS:
- To read (or query) use only HTTP GET
- To publish use only POST and PUT
- Always put request scoping parameters in the URL
- Always express error conditions in HTTP response headers
What about complex filters with OGC XML expressions too long for the query string? First of all, this is a WFS bug and web server bug, not a REST bug. I've got some ideas about how to solve this using resource-oriented design (future post), but will stick to basic REST here.
RFC 2616 states:
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
- Providing a block of data, such as the result of submitting a form, to a data-handling process;
- Extending a database through an append operation.
Does this invite us to POST filters after all? No. The WFS filters help describe the scope of the request. They are not part of the representation of a new resource, or data to be processed. Splitting request scoping between the URL (typename, bbox) and the request body (posted filters) seems to me to be the worst of both worlds. Better to put all scoping in the HTTP request body (if you must) and call it XML-RPC or SOAP, or put it all in the URL and call it RESTful.
Similarly, a RESTful WFS has to take advantage of the response status header. Its clients are HTTP clients first and foremost, not WFS clients. If the client sends a mangled request, reply with a 400 Bad Request. If the WFS filters screened out everything, reply with 204 No Content. By all means, do put a more verbose message in the response body, but the status header is more important to an HTTP client.
Ignoring service capability and feature type metadata for the moment, the above is all that's needed to produce a basic REST-RPC hybrid service.