Re: [Geo-Web-REST] RESTful web service interface description

[Pat Cappelaere]

Sean,

So what is your position on this for OGC services?
Tim Bray is wavering on WADL and thinks YAGNI.
Sure APP is the bare minimum to have but this is not enough.

Any OGC Service that uses a RESTful interface will have to extend the
Protocol and expose specific data attributes within a particular collection.
How do you tell that to the client?
It is not in the APP service. If it is not in the WADL, where is it?

Google Gdata has been trying to define a way to query for metadata
http://www.google.com/base/api/demo/html/demo.html#metadata

This is something that we are trying to leverage but the feedback is not too
positive (
http://groups.google.com/group/wfxml/browse_thread/thread/c03dcb9fa5229add).

This might be the best example we have to follow. Or is it?

What say you?

Feedback from this community is very critical as we are trying to define a
RESTful API for an OGC Workflow Chaining Service that could also be used to
supercede older OGC specifications such as SPS, WPS, SOS...or at least point
to an example.

Pat.

> From: Sean Gillies <sean.g...@gmail.com>
> Reply-To: <geo-we...@googlegroups.com>
> Date: Sat, 19 Jan 2008 10:08:52 -0700
> To: <geo-we...@googlegroups.com>
> Subject: [Geo-Web-REST] RESTful web service interface description
>
>
> Like Tim Bray says, there has been a burst of discussion and opinion.
> Lots of good links from:
>
> http://www.tbray.org/ongoing/When/200x/2008/01/18/Service-Doc-as-Interface-Def
>
> I really appreciate Steve Vinoski's analysis:
>
> http://steve.vinoski.net/blog/2008/01/14/lying-through-their-teeth-easy-vs-sim
> ple/
>
> Vinoski is one of the foremost CORBA experts and I think his perspective
> is a good one for OGC WxS architects to try on, since WxS has its roots
> in CORBA and COM.
>
> Cheers,
> Sean
>
>
> >

[Carl Reed]

Not to be argumentative, but WMS roots are in HTTP and distributed loosely
coupled architectures and not CORBA/COM tightly coupled architectures. Back
then I was an OGC Member and worked with a group of members to move OGC from
CORBA/COM type approaches to a more loosely coupled web based HTTP
architecture pattern. I have all the design documents authored by Allan D
and others that describe the WMS architecture and philosophy if anyone is
interested. I suspect if REST had been around back in 1997/1998, we would
have used that approach. Ain't legacy wonderful?

Cheers

Carl

[Pat Cappelaere]

Now that we are all in agreement with the approach, let's go back to the
original question:

RESTful web service document:

APP, WADL, YAGNI or Google Gdata or something else?

What is this group's opinion?

Pat.

[Pat Cappelaere]

Chris,

Are you saying that "You Ain't Gonna Need It"?
Which means to me that we do not have to describe to data records?
Infer it from the atom feeds and read the spec for commands?
Pat.

> From: Chris Holmes <cho...@openplans.org>
> Organization: The Open Planning Project
> Reply-To: <geo-we...@googlegroups.com>
> Date: Sun, 20 Jan 2008 00:10:56 -0500
> To: <geo-we...@googlegroups.com>
> Cc: <wf...@googlegroups.com>
> Subject: [Geo-Web-REST] Re: RESTful web service interface description
>
> I definitely think we should use YAGNI for the RESTful web service
> document. It's looking to be a real powerful innovation that we can
> successfully harness to solve all our needs ;)

>> !DSPAM:4005,4792c1a7294481030819293!
>>
>
> >

[Pat Cappelaere]

Brandon,

APP is fine for simplistic collections (blogs). Problem is that it does not
help you (that I know of) to define complex collections that contain more
sophisticated records such as OGC Web Feature Service, Planning Service,
Observation Service...or Chaining Service (in my case)...

If there is no way to describe the collection with all its attributes and
metadata, this makes it very hard on the client to infer it and properly
use it, IMHO.
Right?

Pat.

> From: Brandon Carlson <bca...@gmail.com>
> Reply-To: <geo-we...@googlegroups.com>
> Date: Sun, 20 Jan 2008 19:14:52 -0600
> To: <geo-we...@googlegroups.com>
> Cc: <wf...@googlegroups.com>
> Subject: [Geo-Web-REST] Re: RESTful web service interface description
>
>

> I think that for most implementations, I'd say YAGNI, for
> standardization purposes my vote is for APP.
>
> Brandon

[Pat Cappelaere]

Sean,

Planning and Chaining services are still necessary for building complex
sequence of services. The new architecture makes it simpler but the need is
still there.

Since you are mentioning weather station data, let's use that as an example.
So let's imagine that we use APP/Atom, design it right and end up with 2
collections (per example: http://ccc.atmos.colostate.edu/~autowx/):
- Recent Observations
- Soil Temperatures

So I can get an atom feed for each one of those collections.
I suspect that the Atom feed would be extended to something like:

<entry>
...
<g:temp>8.8</g:temp>
<g:RH>65.1</g:RH>
<g:DewPt>-0.5</g:DewPt>
<g:Wind>5.9</g:Wind>
<g:Dir>5.9</g:Dir>
...
</entry>

How do I know what those attributes are, what they mean, what the units
are...? How do you tell clients what they are going to get?

If this is a complex resource, how would you break it up?

Pat.

> From: Sean Gillies <sean.g...@gmail.com>
> Reply-To: <geo-we...@googlegroups.com>
> Date: Mon, 21 Jan 2008 13:47:57 -0700
> To: <geo-we...@googlegroups.com>
> Subject: [Geo-Web-REST] Re: RESTful web service interface description
>
>

> I'm with Brandon on this one. I see a lot of upside to breaking up
> overly complex resources. Maybe they won't ever fit AtomPub (because
> it's not a silver bullet), but if they could be made to do so they'd be
> made widely usable.
>
> Even if you don't use AtomPub, a homepage-like document that links to
> resource collections is still a good thing to present to clients.
> AtomPub doesn't say much about search, so you need complementary forms
> or opensearch documents to describe the search interface to your
> collections. In my own application, I'm going without W*DL and using
> well-known content types (Atom, KML) instead of schemas to tell clients
> what they are going to get.
>
> I've deployed a few Campbell units in my day, and it seems to me that
> senor observations and syndication are a great match. Your typical
> weather station has perfectly flat records. See
>
> http://ccc.atmos.colostate.edu/~autowx/
>
> for example. The folks at the CCC even see the usefulness of RSS,
> although I think their design is somewhat wrong. Planning and chaining
> services ... I can't say since I don't know anything about them. Is it
> possible that they're not really necessary once you switch over to the
> architecture of the Web?
>
> Sean
>
> Pat Cappelaere wrote:
>> Brandon,
>>
>> I do not believe that this is a specific problem with OGC services.
>> If you want to publish a complex resource collection, you will run into that
>> problem.
>>
>> You have to extend the Atom protocol to publish the resource.
>> So my gut feeling would be to extend APP in a similar fashion but I have not
>> seen anyone go that route...AFAIK.

>>
>> Pat.
>>
>>
>>> From: Brandon Carlson <bca...@gmail.com>
>>> Reply-To: <geo-we...@googlegroups.com>
>>> Date: Sun, 20 Jan 2008 23:03:20 -0600
>>> To: <geo-we...@googlegroups.com>
>>> Subject: [Geo-Web-REST] Re: RESTful web service interface description
>>>
>>>

>>>> APP is fine for simplistic collections (blogs). Problem is that it does
>>>> not
>>>> help you (that I know of) to define complex collections that contain more
>>>> sophisticated records such as OGC Web Feature Service, Planning Service,
>>>> Observation Service...or Chaining Service (in my case)...

>>> I understand. Is it that the OGC services are too course grained and
>>> overly complex? Could they potentially be broken down into finer
>>> grained resources that could be more easily handled through APP?

>>>
>>>> If there is no way to describe the collection with all its attributes and
>>>> metadata, this makes it very hard on the client to infer it and properly
>>>> use it, IMHO.

>>> Agreed.
>>>
>>> Brandon