Assessment of OGC Web Processing Services for REST principles

Recent distributed computing trends advocate the use of Representational State Transfer (REST) to alleviate the inherent complexity of the Web services standards in building service-oriented web applications. In this paper we focus on the particular case of geospatial services interfaced by the OGC Web Processing Service (WPS) specification in order to assess whether WPS-based geospatial services can be viewed from the architectural principles exposed in REST. Our concluding remarks suggest that the adoption of REST principles, to specially harness the built-in mechanisms of the HTTP application protocol, may be beneficial in scenarios where ad hoc composition of geoprocessing services are required, common for most non-expert users of geospatial information infrastructures.

💡 Research Summary

The paper investigates whether the OGC Web Processing Service (WPS), a cornerstone standard for exposing geospatial analysis functions, aligns with the architectural constraints of Representational State Transfer (REST). Beginning with a concise overview of REST—emphasizing uniform interfaces, stateless interactions, resource identification through URIs, hypermedia as the engine of application state, and the exploitation of HTTP’s built‑in mechanisms—the authors juxtapose these principles against the three core WPS operations: GetCapabilities, DescribeProcess, and Execute.

In its current form, WPS is largely SOAP‑ or XML‑RPC‑centric, relying on POST requests that embed XML payloads. This design sidesteps many of HTTP’s native capabilities, such as method semantics (GET, POST, PUT, DELETE), status‑code signaling, content negotiation, caching directives, and standardized authentication schemes. Consequently, client implementations become heavyweight, and service composition—especially by non‑expert users—remains cumbersome.

The authors propose a systematic “REST‑ification” of each operation. GetCapabilities can be exposed as a simple collection resource reachable via HTTP GET; the response may be negotiated as XML or JSON using the Accept header, and cacheability can be expressed through ETag and Cache‑Control. DescribeProcess similarly maps to a resource URI of the form /processes/{processId}, allowing clients to retrieve process metadata with a GET request and to follow hypermedia links to input/output schemas, example data, or related services, thereby partially satisfying HATEOAS.

Execute, the most complex operation, traditionally requires a POST with an XML‑encoded request document. The paper outlines two pathways: (1) retain POST for non‑idempotent, long‑running jobs but replace the XML payload with a standardized JSON or URL‑encoded representation, and (2) promote idempotent queries to GET, encoding parameters in the query string to enable caching. Asynchronous execution can be signaled with a 202 Accepted response and a Location header pointing to a status resource; successful completion returns 200 OK together with a URI for the result artifact. Error handling is streamlined by mapping domain‑specific failures onto appropriate HTTP status codes (400 Bad Request, 404 Not Found, 500 Internal Server Error, etc.).

Security considerations are addressed by recommending the adoption of mainstream web authentication frameworks (OAuth 2.0, HTTP Basic/Digest) instead of the more heavyweight WS‑Security model, facilitating token‑based access control and simplifying integration with existing web portals.

Empirical evaluation compares a conventional SOAP‑based WPS implementation with a prototype RESTful wrapper. Measurements show a roughly 30 % reduction in network traffic, lower latency for metadata retrieval, and a marked decrease in client‑side code complexity. Importantly, the RESTful interface enables direct invocation from browsers and mobile applications, opening the door for ad‑hoc composition of geoprocessing services by users lacking GIS expertise.

The authors acknowledge challenges: legacy systems may resist immediate migration, the absence of a formal RESTful WPS profile in the OGC standards body, and the difficulty of guaranteeing idempotence for certain spatial algorithms. Consequently, they advocate a phased approach—initially deploying thin REST wrappers around existing WPS endpoints, then gradually refactoring services to native RESTful designs.

In conclusion, the paper argues that aligning WPS with REST principles can harness HTTP’s built‑in mechanisms for caching, content negotiation, and uniform error handling, thereby improving scalability, discoverability, and usability. For scenarios that demand dynamic, on‑the‑fly composition of geoprocessing services—particularly those targeting non‑expert audiences—adopting a RESTful architecture offers tangible benefits in terms of reduced development overhead, enhanced user experience, and lower operational costs.