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

Sat Jul 13 00:04:36 PDT 2013

Hi Stefan,

so I hear you saying that any database access where a "select...from...where" is 
used cannot be modeled with REST (a select clause does not fit into http path 
syntax). Likewise, those REST services identifying a format via "?f=bmp" are not 
RESTful?

BTW, in your link [1] I do not find that KVP is ruled out, so I'm confused again.

Just for clarification: where is the complete set of rules?
Your link is valuable, but is anything not ruled out there REST?

thanks for educating me,
Peter

[1] http://www.infoq.com/articles/rest-anti-patterns

On 07/13/2013 12:41 AM, Stefan Keller wrote:
> 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)
>>
>>

-- 
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)