In the WFS case, the HTTP DCP has some REST-ful qualities. The operations
defined for a feature type -- insert, update, delete, query -- can
be mapped to the HTTP methods -- POST, PUT, DELETE, GET. But that's the
extent to which the HTTP DCP can be called REST-ful. WFS only concerns
itself with GET and POST. The verbs OPTIONS, HEAD, PUT, and DELETE are ignored,
and instead we get service method dispatching:
request=GetCapabilities
request=DescribeFeatureType, typename=roads
request=GetFeature, typename=roads, filter=...
request=Transaction, typename=roads, data=...
More REST-ful would be to treat feature types as first-class resources:
HEAD http://wfs/types/roads
GET http://wfs/types/roads?filter=...
PUT http://wfs/types/roads/segment1 [data]
WFS has sacrificed REST-fulness on the altar
of interoperability with DCPs that -- as far as I can tell -- aren't significantly used. WFS goes against the grain of the web.
Fine, nothing is perfect. I can hold my nose and use the non-REST HTTP DCP, but there are two annoying issues
that are confounding my latest project:
- No one sets HTTP status codes for service exceptions.
- No one uses sensible mime types to discriminate between a good
response and a service exception.
Why does this matter? I'm writing WMS and WFS client software, for
Python, modeled loosely after xmlrpclib. There are WebMapService and
WebFeatureServices classes, with (among others) .getmap and .getfeature
methods. These methods will return file-like objects (urllib's network
object, specifically) for map or feature responses, but raise exceptions
in the case of a W*S service exception response.
The WMS case is easy: always ask for exceptions in the format application/vnd.ogc.se_xml, and check the content type of the
response. There's no need to look in the response data to determine
whether we have an image or a service exception. This isn't something
you can rely on with WFS instances. Instead, I'm faced with reading
from the network object, parsing the data to find exceptions, and then
rewrapping it in another file object. Yuck. All I need is a 400 status
code or a unique mime type along with the service exception XML. Is
that too much to ask?
Interesting; a few comments:
If someone were to use the native HTTP methods, then that wouldn't that have stuck things more in the hands of the httpd server for configuration? The OGC way, it's easier to decouple and add an auth layer between httpd and the application software (or within the app software). Mind you, it's work either way.
Also, HTTP status codes are totally different things then ExceptionReport codes. An ExceptionReport still comes back as HTTP 200 as it should, i.e. the HTTP response was successful (as a protocol), but the service returns error.
Historical precedent. WMS was developed in 1999, before we had heard of REST. (Note - Fielding's dissertation is dated 2000). WFS was patterened after WMS. I first bumped into REST in 2000 during the 2nd OGC testbed and as much as things made sense to me, it wasn't clear at the time how to turn the momentum towards REST, particularly in the face of considerable pro-SOAP interest. There are certainly things I wish we had done differently for WMS. In particular, I think having a CGI interface to the capabilities document has proven to be a huge impediment to getting people to think about search engine friendly ways of advertising WMS's.
Tom: yeah, my status code idea was naive. Certainly some clients are counting on a 200 along with their service exception. I think the protocol is wrong here. They *should* expect a 400 for a bad request, or a 500 for a WFS server error (db failure or whatever).
Allan: REST has been around longer than that. The intro to Fielding's dissertation states that REST has been guiding the architecture of the web "over the past six years". Despite that, it's been easy to overlook. I totally agree with you about the problem with GetCapabilities.
Thanks for the comments!
Allan: with regard to making OGC services more "search engine" friendly, I think that the upcoming version of OWS common mandates that OGC services generate some descriptive metadata when they are invoked without any parameters. Is this what you had in mind for making OGC service more search engine friendly.
Comment to myself... maybe it was actually the 3rd testbed. It's all a blur :)
Sean - yes, REST has been around as a concept, in fact, it was probably *the* concept before the XMLRPC folk started in and laid the foundation for SOAP. I think we're actually lucky that WMS turned out as it did.
Peter - Holy cow! I just took my first look at OWS Common in a long time. I mean http://foo.org/mywms should have been a perfectly good WMS capabilities URL. I guess that wouldn't neccesarily improve searchability, but it would make it far easier to get results than having to try all the variations of GetCapabilities that have sprung up. Getting back to the upcoming OWS Common... I don't exactly see iPod-like zen. Who's going to implement that stuff!?!?
Yes, I must admit, when I see the page count it does seem rather daunting! However, keep in mind that OWS common gathers up bits and pieces that might be common to a bunch of OGC services ... like BBOX. Theortically it should make the other specification shorter since they only need reference OGC common!?
REST is the anti-SOAP. I know they try to do the same types of things, it's just that SOAP brings all this extra baggage that I never needed. I like REST for it's ease of use. Give me tomcat and dom4j and I am good to go...
Instead of using status codes, why not propose using the same mimetype method as WMS?
Even though having different mime types for seemingly text/xml responses is a pain on occasion, its times like these that it makes detection so much easier.
I'd vote +1 for WFS application/vnd.ogc.se_xml (or something similar).
I have a theory about this: doing good REST requires understanding and using two or three different standards, HTTP for transport, URL/URI for location, some kind of *ML encoding and maybe MIME. If you know all those standards and spend a little time cogitating, it's hard not to end up RESTful.
If you only really know *ML, then you tend to ignore things like HTTP codes or MIME types, and you get stuff like WFS, where almost all the magic happens in the content encoded bundle, and all the rest is treated as anonymous pipes.
The ironic part is that OGC itself is trying to divide up its standards base into lots of little orthogonal pieces... data encoding, data styling, metadata encoding, service profiles. And it is getting swamped by things like KML that stuff all the information into one big block.
WFS is web services ignoring the most of the web. KML is geodata interoperabilty ignoring much of the existing standards base.
OGC originally was trying to steer around the OLE/DCOM vs. CORBA debate. The Simple Features spec actually had a CORBA version, an OLE/DCOM version, and an SQL version. There was always the feeling that the OGC spec had to ride one level above the actual transport since otherwise it would be too hard to move from one to another. And I'm not sure many participants in those days would have been up to speed enough on HTTP/URI/XML to come up with a real REST solution.
KML seems to be swamping everything else because it's easy to hack up quick things w/o having to read very much. You can get better at KML hacking slowly, without having to break much of a sweat. I don't think you can say that about most OGC specs.
Comments are closed after 13 days.
