Here's the take-away from the past year's discussion about REST and geospatial. My own take, that is. There are differences of opinion among the participants of the Geo-Web-REST group.
REST is an architectural style, not an API. When you hear or read "... REST API ...", that's a smell, a signal that something might not be quite right inside.
REST is the architectural style of the World Wide Web. "Web API" is a more meaningful term, although not all Web APIs are RESTful. Some are GETSful.
The OGC service architecture is not RESTful. The style of the OGC architecture is non-RESTful CGI/RPC. Feature, map, and coverage resources are kept hidden behind service endpoints. We're still partying like it's 1999.
GML is compatible with REST, but XML Schema is still a wretched beast and there are no XLink-traversing GeoWeb browsers of note.
Look to Google Earth and KML for REST inspiration. It's about the links. Also look to Google's AtomPub-ish APIs for YouTube, Picasa, and OpenSocial. There's no transactional WFS involved there, and that's something to think about. Google chose AtomPub for wider interoperability.
REST is not a silver bullet. Distributed applications are hard.
These are the tenets of REST:
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
Do read and recommend Stefan Tilkov's Brief Introduction to REST, from which the tenets above are taken. It's excellent.
Disregard the Emerging Technology: Geospatial Web Services and REST article in Directions. I don't care who linked you to it; they probably didn't read it very closely. This sounds mean, but that article will make you dumber about REST.