Re: [wcsplus] WCS REST (was Design of asynchronous request in DEWS WCS)

NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.

Dear all,

(I'm replying to Stefano's email under John's new thread title since
this makes more sense!  I've copied Stefano's email below my message.)

Stefano - this is a really interesting email, thanks.  I must admit
I'm not sure I've fully grasped all the implications of what you say
but perhaps you can help me understand a couple of points:

1) I agree that the REST approach gives a neater and more logical URI
syntax, which can also apply to WMS, WFS etc.  It seems logical to
have a URI that represents a coverage (or Layer in a WMS), and to use
this URI as the base for data and metadata queries.  However I'm
afraid I'm still struggling to see the gains beyond this:

2) The web is highly scalable (largely) because it is
document-oriented and these documents (being generally "not very big")
can easily be cached in various places (in your browser, in proxy
servers, at ISPs etc) so that the load on the primary servers is
reduced.  However, dynamic content is usually not cached (caching
would destroy the dynamic nature) so web servers that serve dynamic
content don't benefit too much from this scalability.  Serving of
"large" files is usually made scalable, not through the caching
system, but through the creation of mirror sites (i.e. an application
outside the architecture of the Web).

3) Web servers are easy to implement because, for static content,
there is a very simple mapping between a filesystem on disk and a URI
hierarchy.  Servers that serve dynamic content are harder to

Given that OWS servers are highly dynamic and will often deal with
large datasets, I can't yet see how a REST approach brings benefits to
efficiency or ease of implementation.  The server still has to do
basically the same tasks of query parsing, data extraction and data
formatting.  To take the example of caching - what do we cache?
Entire coverages (e.g.  I don't
think this is feasible in the general case.  In any case you will need
most or all of your business logic to exist on all cache servers in
the system to support subsetting.

It is of course highly desirable to make OWS servers more efficient
and easier to implement.  However, I'm not sure the analogy with the
Web is valid.  I still think that OWS are query-oriented rather than
resource-oriented: a general WCS server will have "a few" resources
(coverages) but will need to be able to serve an infinity of possible
subsetting queries.  I think a better analogy is with data-driven
dynamic websites, which can only scale up to large number of
simultaneous users through "clustering" the back-end, which of course
adds to the complexity.

Perhaps I'm missing your point though.  It is Monday morning after all! ;-)


On 11/2/07, Stefano Nativi <nativi@xxxxxxxxxxx> wrote:
Dear all,

I really appreciate this discussion which touches several of the
issues we have been discussing and facing in our research and
development activity.

We have been developing OWS on SOAP; recently, we decided to play
with some REST implementations (especially for asynch interactions).
Therefore, I'd like to add some comments stemming from our
understanding of REST and experience with it. Please, forgive the
long content of this email; actually I put together Paolo's and my
comments :-) .

Let me distinguish between the REST approach (the architectural
style) and the RESTful implementation (the current technological
solutions for implementing REST).

The REST approach proved to be highly scalable and sufficiently
flexible in many contexts, primarly the WEB infrastructure but also
DB and filesystem access. In all these cases we have resources
singularly addressed with a uniform interface.

Indeed the possible REST actions are limited by the uniform interface
which tipically maps the simple CRUD (create, retrieve, update and
delete) paradigm. Often simplicity means generality and flexibility
(see the netCDF data model case); in fact, this simplicity was one of
the reason for the WEB pervasive success and for its scalability. On
the other hand, advanced semantic actions (e.g. resource processing
actions) must be mapped to the basic CRUD vocabulary.

For example in the DB domain we can use SQL: a DB is the resource
domain; the uniform interface is made of
SELECT/INSERT/CREATE/UPDATE/DELETE methods; resource-IDs are all the
possible SQL "WHERE" clauses.
For the WEB (which may be seen as a globally distributed DB),
resource-IDs are the WEB URIs (i.e. the "WEB clauses").
In both cases the resource-ID may become really complex (i.e. very
long KVP strings; or complex SQL JOIN SELECTS) and, hence, it may be
difficult to efficiently manage these IDs. For a REST WCS
implementation (at the abstract level; no implementation details),
resource-IDs are the GetCoverage clauses (analogous to the "SELECT"
request content).

In our opinion, this is the real asset/limitation of REST: the
application business logic must be faced and partially addressed at
the interaction level (the protocol level), leaving the rest of the
business logic to the server which, consequently, may result simpler
(almost any Institution can manage a WEB server, today). With the
Service-oriented approach, the entire application business logic is
left to the server (i.e. the service provider) implementing a even
simpler interaction: Exchange/Send an Electronic Document. Thus, SOA
guarantees high flexibility, but the server (the service provider)
has to face all the resource-related issues (e.g. resource caching,
ID, creation, encoding, etc.) anyway.

Thus REST focus is on uniform interface and resource addressing not
on resources nature (discrete, existing, etc.). If we can provide a
uniform interface and a complete resources addressing we can adopt a
REST architecture.
In our opinion WCS seems to be implicitly based on a uniform
interface (since we GET coverages, GET coverages descriptions and GET
server capabilities and we do not explicitly define other action like
INTERPOLATE, SUBSET, etc.), allowing to address each resource. Hence,
a REST architecture seems an effective choice for this domain.

As to RESTful implementation for Geospatial resources, several issues
must be considered.

First of all we should define what "resource" and " resource
representation" are in this domain. We could decide that a dataset is
the resource and all the features extracted from the dataset through
interpolation, subsetting and resampling are simply different
representations. In such case we should only address the dataset with
a known URI and possibly create new resources if required. On the
other hand we could consider each feature extracted from a dataset as
a different resource. In such case we should address each feature
with a different URI.

Presently, we are working on this second approach for some reasons:
for theoretical consistency (according to the Web architecture a
representation should only affect formats), and for implementation
reasons (different URIs could support server-side caching).

Concerning the addressing problem we do not need to explicitly define
URIs for each possible feature. We can simply provide a functional
mapping between a URI-space and resource representations. In the OWS
the URL-encoding of KVP string in a GET request IS the resource
addressing. The fact that the feature is dynamically created is not
an architectural problem but an implementation issue which might
require smart caching servers.

For example:,-90,180,90&;...

is the URI for the feature extracted by the coverage named "foo" with
the interpolation, subsetting and resampling defined by bbox (and
other) parameters.
(A better URI could be defined leaving only non-hierarchical
parameters in the query part of the URI. Something like:,-90,180,90&;...


When the request is encoded in a POST it should be considered as a
query to the root resource which responds with the representation of
the target resource. This could also be viewed as an
extraction-from-dataset service; however, this may introduce useless
complexity since the request is still a GET action. In fact, there
exists an implicit hierarchy of our features, and the root feature
(the "foo" coverage in our example) doesn't support only its own GET
operation, but also the selection of its children via a POST operation.

These considerations seem to be valid not only for WCS but for all
the data access services (e.g. WCS, WFS and WMS). They conform to a
resource-oriented approach and can be implemented in a RESTful
architecture with "minimal" modifications of existing specifications.
Besides, the RESTful implementation might be easily adopted by data
providers, since it should be based on well-known technologies.

The case of WPS and WCTS seems to be different. In fact, they don't
define a uniform interface for the many operations they should
support; on the contrary, they introduce a uniform interface to
receive a message which contains specific operation requests. In this
case we should use the POST method as the extension point for
interaction with HTTP based services which create new addressable
resources (a sort of ending point in the SOA view). In such a way we
should have the advantages of pervasive and scalable data provision
(through the RESTful implementation) and modular and composable
processing (through the service-oriented architecture).

Some possible conclusions:

A RESTful implementation is valuable for scalability and
extensibility (derived by the REST architectural style) as well as
for simplicity (the implementation is simple since it is based on
well-known technology and only simple operations must be supported server-side)

The RESTful implementation seems feasible for data access services
because they are typically resource-based.

The RESTful architecture must interact with a Service-oriented
architecture for basic and advanced processing. XML and HTTP are the
key technologies for bridging.

Thank you for your patience,

Stefano and Paolo

Dr Jon Blower              Tel: +44 118 378 5213 (direct line)
Technical Director         Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre   Fax: +44 118 378 6413
ESSC                       Email: jdb@xxxxxxxxxxxxxxxxxxxx
University of Reading
3 Earley Gate
Reading RG6 6AL, UK

  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the wcsplus archives: