[Requests] GeoServices REST API - Extending current OGC WxS to support REST
ekeighan at cubewerx.com
Fri Aug 17 15:07:18 EDT 2012
1. Evaluator: Edric Keighan, Panagiotis (Peter) A. Vretanos, Jim
Supple -- CubeWerx Inc.
2. Submission: GeoServices REST API
1. Requirement: All
2. Implementation Specification Section Number: All
3. Criticality: Major
4. Comments/justification for changes: OGC Specifications are
already being extended to support REST.
We recommend that OGC members continue to extend existing WxS standards
to support REST, and decline the proposed standard entitled "GeoServices
ALTERNATIVE A - Extend WxS to support REST
OGC members have already been active in introducing support for REST
with the adoption of the OGC WMTS specification in June 2010. Currently
the WFS working group is extending WFS to support REST, while continuing
support for existing bindings (KVP-Get, XML-POST, and SOAP). See CR#
157, OGC Document # 11-080 titled "A REST binding for WFS 2.0", dated
2011-07-15 at https://portal.opengeospatial.org/files/?artifact_id=44852
for more details. It is expected that the expertise gained from this
effort through a standard and collaborative OGC consensus process will
allow OGC members to introduce support for REST to all other WxS at a
much faster pace than the time required to adopt the GeoServices REST API.
* This enhancement process will produce acceptable REST standards that
meet current REST requirements much sooner than the proposed
specification, which is entirely new, redundant and incompatible
with current WxS specifications.
* These new WxS-REST extensions are simple and conceptually similar to
the effort already undertaken by OGC members to introduce other
bindings to OGC WxS.
* It preserves OGC's investment into OGC core geospatial web services
standards, vendors' investment into products using those standards,
significant investments made by OGC Sponsors for commissioning such
interoperable standards, and reduces overall financial risks for a
world-wide geospatial community who has already deployed OGC-based
* It encourages product vendors to support richer products using more
than one protocol within a single product, leading to better
interoperability without increasing technical support costs.
* It permits web services to support more than one protocol accessing
the same content without duplicating storage or synchronize update
transactions, and without increasing operational costs.
* It supports an XML-based encoding.
* It supports GeoJSON, a popular open data format encoding.
* This approach, when extended in the decades to come to newer
technologies, provides a graceful adoption of future innovations and
protects investments in software & services & content.
We believe that none of the benefits from "Extending WxS to support
REST" above would be possible with the proposed "GeoServices REST API",
because of severe flaws in the concept, approach and implementation of
the proposed specification.
ALTERNATIVE B - "GeoServices REST API"
After the initial comments received by the OGC REST SWG and over a year
of effort to address them, the proposed "GeoServices REST API" still
does not attempt to comply with, nor accommodate, existing OGC WxS
standards; nor does it provide support for industry standard XML, nor
GeoJSON. The proposed "GeoServices REST API", as proposed, is an
inferior, confusing, single-vendor product that is incompatible and
directly competing with existing OGC WxS standards in the same market.
The proposed "GeoServices REST API" is not necessary, given that current
core OGC standards, and reference products based on them, are already
being extended to support REST, probably with shorter delivery &
Edric Keighan, Panagiotis (Peter) A. Vretanos, Jim Supple
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Requests