It’s not enough to just expose these interfaces as URIs and have them be crawled and discovered, as we STILL have to know some specific things about these interfaces, again, what specific capabilities they have and what specifically it’s expecting and providing (Can you give me a .png image? Can your image show major highways as a 3 pixel wide line? Can you give me results as a JSON response? What units of measure are you using? Lat/Long? SPCS? What datum? How DO you represent Lat/Long – DDDMMSS? DDD.DDDD? 360 degrees or +/-180? Can you intersect that dataset with another and give me those results? – and those questions HAVE to be answered, we can’t just shrug them off, and YES, EXACTLY, they are NOT easy or obvious questions to answer, and have NOT yet fully been answered) – It’s never safe to just make assumptions about what the API might or might not do, or what the developers on the other end actually had in mind. And those are the critical questions that we need to wrap our heads around as a community.

While these questions are awaiting answer, are we to just stop everything and say “Um, we can’t build an SDI because we have to wait for the Geo REST community to catch up and answer these questions”? No, we can’t do that either. The needs are now, the needs have existed all along, the effort’s already been ongoing for over a decade, and is all the more are needed if we are to invest in infrastructure. So again, as I’ve said all along, support a hybrid melange, with support for legacy AND newer technologies, practices and approaches.

My primary concern, as @seangorman pointed out, is that Geo- too often thinks of itself as the leading factor in developing an architecture or solution rather than as just an aspect of a large architecture.

These various, and important, questions about services, queries, etc. are broader concerns. Doing a bounding box search is not much different from a time search or person or related query.

We should be looking to and aligning our geospatial tools with generic interfaces. This was the point behind GeoRSS and OpenSearch-Geo. Already broadly implemented and accepted standards of RSS, Atom, and OpenSearch that merely needed “geo” added to them was simpler in terms of design as well as developer acceptance.

Where our expertise comes in is in answering very domain specific questions: coordinate order and CRS definitions, industry standards for return formats such as GeoTIFF, shapefiles (fun in themselves in asking about how to represent multiple files as a single resource). But the answers should fit within the non-geo frameworks and interfaces.

Actually, the beauty of REST is that you *can* talk about it in generic ways — a system’s RESTfulness has very little to do with the specific task it is accomplishing — those are domain concerns and while obviously important, have very little to do with a systems RESTfulness (and, it follows, appropriateness for the web). If domain concerns are leaking into your interface beyond the standardization of formats (media types) and link relations, then you are not designing a RESTful system.

I do not mean to be snarky, but your comment “how do we consistently construct a RESTful URI which will fetch all features within a given bounding box” again betrays a fundamental misunderstanding about what constitutes a RESTful system. REST say nothing whatsoever about URI construction beyond the fact that they need to be opaque. My best guess as to what might consititute a “RESTful URI” would be whether it was exposed via hypertext (and thus discoverable). URI construction based on anything other than links in hypertext (e.g., by some documentation saying here’s how you embed lat/lon in a URL) is inherently unRESTful. Constructing good URIs may be important for other aspects of a system, but it has nothing to do with REST.

I’ll just add — your question might reasonably be reframed as such: “When performing a GET request on the URI representing a bounding box, what format will the returned representation be in, and what link relations are defined in that representation that will lead the user (human or machine) to representations of all of the features it contains)?”

I fear that REST, by embracing genericism and simplicity, is misunderstood to be “easy” or “obvious” — it is neither. It is a very disciplined approach to building distributed systems. I am not addressing your specific concerns because those have nothing to do with REST. Here are the first few important questions to ask: “Does every important resource have a name (i.e., URI)?”, “What does it mean to GET/PUT/DELETE to a URI?”,”Are those actions appropriately idempotent?”, “Have I designed resources that accept POST requests to create new resources?”,”What media type(s) will a request return?”, “What media type(s) will a POST accept?” These are questions that any RESTful system will address.

I think the cognitive dissonance here is that conversations are going on about two different layers — the domain layer and the interface layer. The confusion arises because in more RPC-ish systems, the two are entwined and must be discussed together. The beauty of a REST approach is that the interface is abstracted and can be approached in itself — domain concerns mainly arise in decisions around *formats* NOT *actions*.

REST is neither easy, nor is it a silver bullet. Designing good systems is extremely difficult no matter how you slice it. But what REST offers in terms of transparency, interoperability, and evolvability could be extremely useful to the GIS community. To not take a hard look at what needs to be done to make things more RESTful would be a missed opportunity.

Again, if you go back and actually _read and consider_ what I’m saying above, you will see that I make the point of fundamental questions like, how do we consistently construct a RESTful URI which will fetch all features within a given bounding box, or within a given radius, or within a buffered distance, and so on. Are we talking bounding box in lat/long? Or are we talking SPCS? Are we talking buffer distance in feet, km, miles? You might structure that RESTful URI in one way, another person might structure it in another way. Yes, folks are doing these things in a RESTful fashion, but in many instances, without any consistency among them as of yet other than within the scope of each individual application. How do we build desktop client software and server-to-server software to transparently discover, connect to and use them? You keep answering the GENERIC questions of REST which were not asked, but which have already been answered over and over, but as of yet, nobody has addressed these kinds of SPECIFIC questions. And the reason is, that nobody yet has the answers. The answers will come, but again, that is why we need to anticipate and be ready for and promote the maturation of RESTful geo implementations, but in the meanwhile, still be able to function with and accomodate the tens of thousands of services and assets already out there.

@Sean Gorman Gotta work 24/7 to keep up with me, there’s no such thing as a weekend off ;^) – IMHO, not enough people are talking about what Vivek Kundra’s appointment means in terms of geo. I’m one of the very few who is: http://surveying-mapping-gis.blogspot.com/2009/02/nsdi-for-democracy.html – and if you look at what he did for the District of Columbia with his Open Data Catalog, essentially what he did is build and promote a (say it with me) SDI for DC, and lo and behold, it’s turned out to be a huge success. Again, SDI is about facilitating informed discovery and access. It’s NOT some shrink-wrapped piece of ESRI software, nor is it about some one group of folks going out and finding data sets and bringing them into their own environment and massaging them so that folks can use some “one-stop shopping” portal to build mashups. It’s about collaboration, participation, contribution, and so on.

My take is that in order to make itself truly relevant the geospatial niche needs to make itself meaningful and accessible to the mainstream. This starts with IT and the Web. GIS in general has operated outside of the IT mainstream for years. Creating funky proprietary approaches to things and sometimes even rolling those up into standards. The problem is often no one uses the standards, simply because that is not the way the rest of the world works.

There is a great piece in the NYT on the opportunities to revamp broken systems in times of crisis, because it presents the chance the avoid special interests that normally stand in the way.

http://www.nytimes.com/2009/02/01/magazine/01Economy-t.html?pagewanted=all

A lot of folks have talked about the impact of Vivek Kundra’s appointment at OMB. At the DC OCTO he had a running portfolio assessment of all IT projects. Projects that were not providing a good return on investment would either be killed or require a hostile takeover. Meaning the project was a bad idea, so why throw good money after bad – simply cut your losses. Or the idea was good and the implementation team stunk, so you replace the team. Looking at the track record of SDI’s over the last thirty years and the amount of money invested into them, you have to wonder how it would stack up in such a portfolio analysis.

“For example, how do we handle and deal consistently with spatial extents, datums, projections, temporal slices, different types of spatial queries and filters, how can we process and analyze this data –in many ways, the geospatial community is only just beginning to look at how to implement these types of things in any kind of consistent fashion. OGC has already been looking at these questions for some time, and does have some pieces worked out – some of which can and are being adapted to RESTful approaches by various folks. Adopting RESTful patterns and practices is only *part* of the design question, it is not the design question in and of itself.”

It sounds very much to me like you are ignoring the idea of a “uniform interface” Here’s a bit from Roy F.’s dissertation:

“”"
5.1.5 Uniform Interface

The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6). By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability.
“”"

I’ll quote one other bit from Roy, this from a recent thread on rest-discuss:

“”"
“All important resources should be identifiable by URI.”

I think you should look at each of those words in turn and consider why they were chosen. That particular quote is from

http://www.w3.org/2001/tag/2002/01-uriMediaType-9
and
http://www.w3.org/2002/04/22-tag-summary

but it was also in the first drafts of the TAG’s webarch. That principle was not new — I remember TimBL mentioning it during his keynote in Geneva, May 1994, and it dates from Engelbart’s work:

http://www.bootstrap.org/augdocs/augment-132082.htm#11K

which in turn influenced my design when HTTP/1.0 needed finishing. By definition, working on improving the Web Project meant increasing the number of Web-accessible resources.

Here is a more recent variation on the same theme that I just ran across while doing a search:

http://derivadow.com/2007/12/28/web-design-20-its-all-about-the-resource-and-its-url/

Other things that might be worth keeping in mind is that REST is designed for reuse, not just use. The notion that anyone has control over a successful application’s reuse is pure fantasy, as described in

….Roy
“”"

There is a whole lot of wisdom there, it seems to me, and might (I’d hope) give some food for thought to the GIS community.

–peter

For example, how do we handle and deal consistently with spatial extents, datums, projections, temporal slices, different types of spatial queries and filters, how can we process and analyze this data –in many ways, the geospatial community is only just beginning to look at how to implement these types of things in any kind of consistent fashion. OGC has already been looking at these questions for some time, and does have some pieces worked out – some of which can and are being adapted to RESTful approaches by various folks. Adopting RESTful patterns and practices is only *part* of the design question, it is not the design question in and of itself.

Meanwhile, we have to recognize and deal with the fact that, across the country, there are tens of thousands of organizations, state, county, local government, NGOs, academia and others, who currently host a gamut of geospatial data and resources, easily many tens of thousands of individual layers and assets, as OGC WxS, ArcIMS, ESRI shapefiles, and so on – we can’t just turn our backs on these assets simply because they aren’t RESTful.

For Sean, I have never suggested REST as an “afterthought”. From the outset, I have quite consistently been suggesting RESTful patterns and practice in conjunction with with legacy WxS and other services – you will also see this echoed in the NSDI2.net proposal and elsewhere – it’s anticipated that we would need to support a hybrid mélange of technologies. From the outset, I have been suggesting that we need to be forward-thinking, to accommodate new and better patterns and practices as they emerge – while at the same time still accommodating legacy approaches and technology. Just as it would be a grave design flaw to NOT have a RESTful vision moving forward, it would likewise be a grave design flaw to NOT support all of the tens of thousands of WxS and other legacy assets already out there.