[OSGeo-Standards] Was: "file" formats. Is: GeoWeb

Fri Jul 12 15:41:26 PDT 2013

Hi Peter

Regarding KVP not being RESTful please let me point again to the book
(not the PhD thesis!) and the REST anti-patterns.
A resource is that part before "?" mark. How can you distinguish else
a ressource KVP from a temporary token KVP?
The beef is in the lean design of a protocol.
In REST it's in using http, URLs, mime types - and Atom Pub.

Yours, Stefan

2013/7/12 Peter Baumann <p.baumann at jacobs-university.de>:
> Hi Stefan,
>
> like with other statements on what is RESTful and what not in this thread, I
> fail to find out what it's concretely.
>
> Still I am missing a commonly agreed, if not authoritative set of rules (not
> a PhD thesis!). I'd expect that, after these years of hot debates, the REST
> community has matured into a set of commonly agreed rules.
>
> Please let's not use KVP as a measure of RESTfulness, as long as stanzas
> like
>     ...?f=bmp
> are considered RESTful. And, BTW, any SQL query you need to send through KVP
> as the path syntax cannot represent it.
>
> So, one more time: where's the beef?
>
> thanks fo educating me,
> Peter
>
>
>
>
> On 07/12/2013 11:01 PM, Stefan Keller wrote:
>>
>> Hi Carl
>>
>> I apologize of sometimes being rude especially about OGC spec. I
>> accept OGC's role in standardization. To me this means high
>> responsibility and therefore I'm having high expectations about the
>> quality of the process and the output.
>>
>> 2013/7/12 Carl Reed <creed at opengeospatial.org>:
>>>
>>> Interesting comment "WMTS is not RESTful yet because of other reasons".
>>> There is a presentation on the OGC website that documents Why WMTS is
>>> RESTful. This presentation was provided as part of the approval process
>>> for
>>> WMTS.
>>
>> I did'nt find the presentation. Can you give me a link?
>>
>> To backup my opinion that most OGC WxS aren't really fully RESTful I'd
>> like to point to the REST anti-patterns [1].
>> AFAIK most WxS including "WMTS using HTTP KVP encoding" (chap. 8) [2]
>> use anti-pattern 1 and 2 ("Tunneling everything through GET and
>> POST").
>> And WMTS is "overengineered" among others because it requires that "A
>> WMTS client SHOULD support both KVP and RESTful" (chap. 11.1).
>>
>> Yours, Stefan
>>
>> [1] http://www.infoq.com/articles/rest-anti-patterns
>> [2] http://www.opengeospatial.org/standards/wmts
>>
>>
>> http://www.infoq.com/articles/rest-anti-patterns
>>
>>
>> 2013/7/12 Carl Reed <creed at opengeospatial.org>:
>>>
>>> Stefan -
>>>
>>> Interesting comment "WMTS is not RESTful yet because of other reasons".
>>> There is a presentation on the OGC website that documents Why WMTS is
>>> RESTful. This presentation was provided as part of the approval process
>>> for
>>> WMTS.
>>>
>>> This inability to agree on what a RESTful service is (or the interface)
>>> has
>>> plagued REST work in the OGC for years. This is why the OGC Architecture
>>> Board suggests a pragmatic approach - implement REST interfaces for
>>> several
>>> existing OGC standards (WFS, WPS, WCS etc) and find out what in practice
>>> (not in the abstract) a RESTful OGC web service is and then document the
>>> best practice and guidance for future work.
>>>
>>> Also, GeoPackage defines rules for a container of geo-content (binary).
>>> These rules (requirements) define the internal format for storage on a
>>> device. The geometry elements are in line with OGC/ISO Simple Features
>>> and
>>> ISO 19107.
>>>
>>> Cheers
>>>
>>> Carl
>>>
>>>
>>>
>>>
>>> -----Original Message----- From: Stefan Keller
>>> Sent: Friday, July 12, 2013 3:27 AM
>>>
>>> To: Rushforth, Peter
>>> Cc: standards at lists.osgeo.org
>>> Subject: Re: [OSGeo-Standards] Was: "file" formats. Is: GeoWeb
>>>
>>>
>>> Hi Peter
>>>
>>> Thanks for the discussion. I think the book "REST in Practice" fits
>>> your thoughts and can be recommended for all as a basic lecture:
>>> http://restinpractice.com/book/
>>>
>>> As you say what's crucial to GeoWeb - and rather understimated in REST
>>> discussion until now - is the contract. That's why I like the above
>>> mentioned book. Producing a broadly accepted contract - accepted not
>>> only among us but even by browser manufacturers - makes it so
>>> difficult.
>>>
>>> You say there should be a contract against a server and a format, and
>>> a format and a client. That's interesting, But when separating the
>>> server-client-contract don't you loose something like state change
>>> protocol metadata (and negotiation) which you also have in a contract?
>>> To me that's where "WSDL for REST" comes in.
>>>
>>> Web map raster tiles already come close to a format since its JPG, PNG
>>> etc. (and WMTS is not RESTful yet because of other reasons). Perhaps
>>> the grouping information could go into the protocol metadata? For
>>> raster to me there's no need for links - except the spatial
>>> relationship which already is powerful.
>>>
>>> For vector features and feature collections we already have xlink and
>>> grouping - to there's nothing to do here for a contract I think. To me
>>> the elephant in the room is which format: Interestingly neither
>>> GeoJSON nor GeoPackage have been mentioned yet!?
>>>
>>> Yours, Stefan
>>>
>>>
>>> 2013/7/11 Rushforth, Peter <Peter.Rushforth at nrcan-rncan.gc.ca>:
>>>>
>>>> Arnulf,
>>>>
>>>>> Which is why the underlying architecture paradigm is called resource
>>>>> orientation.
>>>>
>>>>
>>>> Resource and representation is part of REST, yes.  Let's try to be a bit
>>>> clear about terminology.  At least REST has a definition.
>>>>
>>>>> If we take some raster data to be the resource
>>>>
>>>> I would say that's not a great starting point for a resource data model.
>>>> Maybe "the earth", or some part thereof would be a more concrete
>>>> concept?
>>>>
>>>>> then any part and information derived from this data is a
>>>>> representation
>>>>> of this resource.
>>>>
>>>>
>>>> Yes, that's one aspect of the resource-representation duality: the
>>>> server
>>>> is free to serve up a partial representation of the whole resource, not
>>>> only
>>>> different formats, languages etc. The partial nature of the
>>>> representation
>>>> is mitigated by the ability to include links to other parts in
>>>> hypertext.
>>>>
>>>>> It is perfectly fine for a representation (for example a file) to not
>>>>> have any hypertext component or link embedded in them (think PNG
>>>>> image).
>>>>> It can still be part of a REST environment. The raster representation
>>>>> that is returned for a GET request could well be wrapped into some
>>>>> hypertext, this would make things even nicer but is not required at all
>>>>> times.
>>>>
>>>>
>>>> I'm not sure what you mean by "at all times".  That statement is taken
>>>> by
>>>> most
>>>> "REST APIs" to mean "never", or "only incidentally, but not required by
>>>> this spec"
>>>> from what I've seen.
>>>>
>>>> We should be starting the other way around, IMHO where we're defining
>>>> the
>>>> hypermedia
>>>> context for services, and let implementers work out their own rules for
>>>> the URI
>>>> for this image or that coverage.  Note that hypermedia can be quite
>>>> sophisticated,
>>>> with standards-based URI Templates [1]
>>>>
>>>> Cheers,
>>>> Peter
>>>>
>>>> [1] http://tools.ietf.org/html/rfc6570
>>>> _______________________________________________
>>>> Standards mailing list
>>>> Standards at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/standards
>>>
>>> _______________________________________________
>>> Standards mailing list
>>> Standards at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/standards
>>
>> _______________________________________________
>> Standards mailing list
>> Standards at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/standards
>
>
> --
> Dr. Peter Baumann
>
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baumann at jacobs-university.de
>
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com, mail: baumann at rasdaman.com
>
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis
> ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
> destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
> 1083)
>
>