[Requests] GeoServices REST API - Phased Approach, Hybrid Architecture

Jeff Harrison jharrison at thecarbonproject.com
Wed Aug 15 13:32:43 EDT 2012


PART A

1. Evaluator: Jeff Harrison, The Carbon Project

2. Submission: GeoServices REST API - Phased Approach, Hybrid Architecture

PART B

1. Requirement: All

2. Implementation Specification Section number: All

3. Criticality: Major

4. Comments/justifications for changes:

The GeoServices REST API Candidate is a very extensive specification consisting of multiple component APIs encompassing a variety of geospatial services, many of which overlap with current OGC Services. It is built on a Core that is extended for associated GeoServices.

Due to the broad nature of the draft specification and the concerns of the OGC baseline, as well as alignment of individual API components, this suggestion is to adopt a phased approach to the proposal, feedback, harmonization, development and acceptance of these parts. This suggestion also proposes integration of interoperability points to enable the use of existing OGC Services in a hybrid architecture. This suggestion also recognizes comments on 'Phased Approach' by Andrew Turner, Esri.

By adopting a phased approach discussion can be focused on developing a common, consensus-based Core. Following this there could be component API development and acceptance of associated services, which include interoperability points enabling use of both REST and SOA-based mechanisms depending on market or enterprise needs. For example, after the Core, develop the Geometry and Feature service, and in a third phase the Catalog and Map service, and finally the Geoprocessing and Geocoding services. Within the Core, for example, there could be a REST 'Landing Page' that allows discovery and invocation of REST services when the need is for optimized web performance, and the ability invoke SOA operations when more complex geospatial needs are encountered by applications or users.

In addition to more focused discussion this phased/hybrid approach would allow developers to build reference implementations and verify concepts along the way. Within this development issues could be resolved before moving onto the next set of services. Simple interoperability points could also identified which allow use of existing services, mitigating issues voiced already by OGC Membership and the geospatial community.

Through such a phased roadmap the entirety of the specification could be adopted but in a stepped approach to achieve a consensus outcome with focused discussion, interoperability points to enable use of existing baseline services when needed and solid implementations to prove the concepts.

This approach would increase interoperability,  enable data services reuse, support client and server applications with a consistent set of APIs, reduce development costs and risk, and promote adoption of OGC specifications in the market. 

--

Jeff Harrison
CEO, The Carbon Project
Twitter: @JeffHarrison




More information about the Requests mailing list