[CITE-Forum] [REST.SC] [Architecture.dwg] [CITE.SC] Resource Oriented Architecture

Ethan Davis edavis at unidata.ucar.edu
Wed Dec 15 23:32:53 EST 2010


Hi John, all,

Also, depending on the specification, there will be times when it is
important to test that the server's state changes upon the proper
requests from an authorized client. So, not just crawling an existing
graph of linked resources but also modifying that graph and checking
that it was appropriately modified.

Ethan

On 12/15/2010 9:21 AM, Philippe Duchesne wrote:
> 
> Hello John,
> 
> as REST is mainly about exchanging hyperlinked representations of
> resources, i think testable requirements should be of the form "for a
> given resource A, does the server return a representation that contains
> all the hyperlinks that A is supposed to have"  (beside the obvious
> syntactic validity of the representation)
> 
> That assumes that, for a given specification :
>   - the set of relevant resource types is identified,
>   - the specification defines the required or optional links between
> those resource types
>   - a set of representation formats are supported; those formats are
> able to represent hyperlinks
>   - concretely, the test engine is able to fetch a resource via its URL,
> parse the returned format, recognize hyperlinks and validate the
> resulting resource graph
> 
> Ideally, an automated test engine should only need the root node of a
> given repository, and be able to browse and validate the whole graph by
> following links.
> 
> --p.
> 
> On 15/12/2010 16:15, John Herring wrote:
>>
>> Pat,
>>
>>  
>>
>> The problem is in two parts, both of which may be simple, but to both
>> of which we must come to some sort of agreement.
>>
>>  
>>
>> 1.    How do you state testable requirements on a RESTful application
>> in an OGC implementation standard?
>>
>> 2.    Once those requirements are clear, how do we build an automated
>> testing system that verifies those requirements are met, so that OGC
>> can grant certified conformance to the implementations of those standards?
>>
>>  
>>
>> It may be quite easy to describe how those requirements might be
>> tested by a person; the question at hand is how do we automate and
>> instrument those tests.
>>
>>  
>>
>> Regards,
>>
>> John
>>
>>  
>>
>> There is inherent danger in being the second lemming in a parade.
>>
>>  
>>
>> The opinions expressed in this email are purely my own and do not
>> necessarily
>>
>> represent the opinions of any organization or otherwise sane person or
>> persons.
>>
>>  
>>
>> John R. Herring
>>
>> Architect, Spatial Products
>>
>> Oracle Corporation
>>
>> One Oracle Drive
>>
>> Nashua, New Hampshire 03062
>>
>> ph: +1 (603) 897 3216
>>
>> fx:  +1 (603) 897 3334
>>
>>  
>>
>> Annue cœptis - Novus Ordo Seclorum
>>
>>  
>>
>>  
>>
>>  
>>
>> -----Original Message-----
>> From: Pat Cappelaere [mailto:pat at cappelaere.com]
>> Sent: Wednesday, December 15, 2010 9:56 AM
>> To: John Herring
>> Cc: 'Arnulf Christl'; architecture.dwg at lists.opengeospatial.org;
>> rest.sc at lists.opengeospatial.org; cite-forum at lists.opengeospatial.org;
>> cite.sc at lists.opengeospatial.org
>> Subject: Re: [REST.SC] [CITE.SC] Resource Oriented Architecture (was:
>> Re: Dec 14th Client Testing Webinar)
>>
>>  
>>
>> John,
>>
>> Where do you think the problem is?
>>
>> I have no problem testing my RESTful service.
>>
>> From the service document, I can find the published collections and
>> end-points and follow the urls from there.
>>
>> Regards,
>>
>> Pat.
>>
>>  
>>
>> On Dec 15, 2010, at 9:49 AM, John Herring wrote:
>>
>>  
>>
>> > I think we may need a little input from the REST.sc on this puppy.
>> If we are going to write
>>
>> > implementation standards using REST mechanisms, we need to know how
>> we want to test
>>
>> > implementations of those standards.
>>
>> >
>>
>> > BTW, I understand why there are no "servers" as the resources and
>> representations play that
>>
>> > role, but are there not still "clients" in the sense that something
>> has to be able to navigate
>>
>> > through the RESTful representation graph, possibly a user, a piece
>> of intelligent software or a
>>
>> > web crawler?
>>
>> >
>>
>> > Regards,
>>
>> > John
>>
>> >
>>
>> > There is inherent danger in being the second lemming in a parade.
>>
>> >
>>
>> > The opinions expressed in this email are purely my own and do not
>> necessarily
>>
>> > represent the opinions of any organization or otherwise sane person
>> or persons.
>>
>> >
>>
>> > John R. Herring
>>
>> > Architect, Spatial Products
>>
>> > Oracle Corporation
>>
>> > One Oracle Drive
>>
>> > Nashua, New Hampshire 03062
>>
>> > ph: +1 (603) 897 3216
>>
>> > fx:  +1 (603) 897 3334
>>
>> >
>>
>> > Annue cœptis - Novus Ordo Seclorum
>>
>> >  
>>
>> >
>>
>> > -----Original Message-----
>>
>> > From: cite.sc-bounces+john.herring=oracle.com at lists.opengeospatial.org
>>
>> >
>> [mailto:cite.sc-bounces+john.herring=oracle.com at lists.opengeospatial.org]
>> On Behalf Of Arnulf
>>
>> > Christl
>>
>> > Sent: Wednesday, December 15, 2010 7:40 AM
>>
>> > To: architecture.dwg at lists.opengeospatial.org
>>
>> > Cc: cite-forum at lists.opengeospatial.org;
>> cite.sc at lists.opengeospatial.org
>>
>> > Subject: [CITE.SC] Resource Oriented Architecture (was: Re: Dec 14th
>> Client Testing Webinar)
>>
>> >
>>
>>>
> Just some thoughts that came to me after John asked a question about how
>>>
> to test RESTful clients.
>>>
> 
>>>
> Looking at this problem from an architectural point of view (instead of
>>>
> from a "RESTful software" perspective) the resources are the inportant
>>>
> entities and there are no clients and no servers but only resources and
>>>
> representations. In the ideal Resource Oriented Architecture the state
>>>
> of an "application" is transferred with each request as part of the
>>>
> resource's representation. This would mean that a (WMS) map that is
>>>
> returned from a server would simply include a FeatureInfo request "hint"
>>>
> encoded as a URL - if the service supports querying. The client can use
>>>
> this "hint" to offer this feature to the user (if the client implements
>>>
> querying). The user clicks on the map (pixel coordinates) which are
>>>
> added to the request including the real world coordinates of the map
>>>
> image (which always need to be delivered together with the response map
>>>
> from the service - er - the resource state).
>>>
> 
>>>
> The rest is unchanged standard WMS processing, take the local pixel
>>>
> coordinates + real world coordinates, calculate click position, query
>>>
> the data, send the representation of whatever was found back to the
>>> client.
>>>
> 
>>>
> The important bit in the whole story is that the client does not need
>>>
> any a priori knowledge of the service to be able to query it - and can
>>>
> thus not really create "wrong" queries. IUt is being told what it can do
>>>
> anytime it can do it. In real life we would all expect some intelligence
>>>
> in the client, if only for convenience. But the interesting bit is that
>>>
> the test is done way before implmenting any software, it is more like
>>>
> test driven standard development (if that term did not exist then it was
>>>
> just invented).
>>>
> 
>>>
> If we go back to unloved Richardson's and Ruby's RestFUL Web Services
>>>
> book they have a simple recipe how to design RESTful services. It
>>>
> involves 4 steps:
>>>
> 
>>>
> 1. Identify the resources and accordingly define the URIs
>>>
> 2. Deciding the data format for each resource (representations of the
>>>
> resource).
>>>
> 3. Methods supported at each URI (~which of the 4 HTTP CRUD operations
>>>
> are supported for each resource).
>>>
> 4. Deciding the response and status code to be returned to the client.
>>>
> 
>>>
> And in more detail -
>>>
> 1. Figure out the data set.
>>>
> 2. Split the data set into resource.
>>>
> For each kind of resource -
>>>
> 3. Name the resource with URIs
>>>
> 4. Expose a subset of the uniform interface
>>>
> 5. Design the representation(s) accepted from the client
>>>
> 6. Design the representation(s) served to the client
>>>
> 7. Integrate the resource into existing resources, using hypermedia
>>>
> links and forms
>>>
> 8. Consider the typical course of events: event flow
>>>
> 9. Handle the error conditions (an example error could be an Update to a
>>>
> resource that does not exist yet).
>>>
> 
>>>
> Step 9 sort of polishes the process off and immediately takes care of
>>>
> testing. This all happens before we implement any software. For us this
>>>
> could mean that we standardize the process of designing a resource and
>>>
> responses instead of designing interface standards, letting them loose
>>>
> on developers and afterwards ask ourselves how we could test what we
>>>
> invented.
>>>
> 
>>>
> Talking about "Testing RESTful APIs of OGC service" (which have not been
>>>
> designed to be RESTful at all) waters down the clear resource oriented
>>>
> principles quite a bit. They seem to suggest that the request to a
>>>
> resource could be in a way "wrong" - which is probably a "wrong"
>>>
> interpretation of the whole REST idea.
>>>
> 
>>>
> Is this only brain damaged nit picking or does it make any sense?
>>>
> 
>>>
> Have fun,
>>>
> Arnulf.
>>>
> 
>>>
> Luis Bermudez wrote:
>>>
>>> >> All,
>>>
>>> >>
>>>
>>> >> We had a fantastic session today with about 10 participants. where
>>> Chuck Morris from Northrop
>>>
> Grumman presented a client testing capability. The  steps presented
>>> were as follows:
>>>
>>> >>
>>>
>>> >> - Following a similar procedure as for a server testing, a new
>>> session was started
>>>
>>> >> - A WMS test suite was selected: OGC WMS client  1.3.0
>>>
>>> >> - A form appeared
>>>
>>> >> - A get Capabilities URL for an existing server was provided: A WMS
>>> service from a local
>>>
> degree installation.
>>>
>>> >> - A proxy URL was then provided by TEAMEngine to be invoked by the
>>> client
>>>
>>> >> - A client (Gaia) was opened
>>>
>>> >> - The client was given the proxy URL
>>>
>>> >> - Several operations were triggered from the user interface in the
>>> client (zoom ,etc..)
>>>
>>> >> - TEAMEngine reported on the validity of the request perform by the
>>> client.
>>>
>>> >>
>>>
>>> >> From the discussion:
>>>
>>> >> - Need a set of operations for a client to be tested.
>>>
>>> >> - If the client doesn't performed all the expected operations then
>>> the report should say so.
>>>
>>> >> - The report should also tell about operations that the client
>>> performed but that were not
>>>
> tested.
>>>
>>> >> - Need to do a comprehensive revision to make sure that the current
>>> WMS 1.3.0 client CTL tests
>>>
> take into account all the WMS 1.3.0 client-related requirements.
>>>
>>> >> - This client testing will be merged to the main code and the test
>>> will be available soon in
>>>
> the beta web site.
>>>
>>> >>
>>>
>>> >> The recording is available here:
>>>
>>> >>
>>>
> 
>>> https://opengeospatial.webex.com/opengeospatial/ldr.php?AT=pb&SP=MC&rID=19707657&rKey=cf1de92d2f
>>>
> 5f2017
>>>
>>> >>
>>>
>>> >> The last 10 minutes of the recording has a discussion about details
>>> of the source code, which
>>>
> may or may not be of interest to some folks.
>>>
>>> >>
>>>
>>> >> Cheers !
>>>
>>> >>
>>>
>>> >> Luis
>>>
>>> >> -------------
>>>
>>> >> Luis Bermudez
>>>
>>> >> lbermudez at opengeospatial.org 
>>>
>>> >> +1 (301) 760-7323
>>>
>>> >>
>>>
>>> >> The OGC: Making Location Count...
>>>
>>> >> http://www.opengeospatial.org/contact
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> On Dec 14, 2010, at 9:52 AM, Luis Bermudez wrote:
>>>
>>> >>
>>>
>>> >>> All,
>>>
>>> >>>
>>>
>>> >>> This is a reminder that we are going to have a CITE Client Testing
>>> meeting at 10:00 am,
>>>
> Eastern Standard Time (New York, GMT-05:00)
>>>
>>> >>>
>>>
>>> >>>
>>>
> 
>>> https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&PW=NOTcwMGQ5ZjFj&RT=MiM
>>>
> xMQ%3D%3D
>>>
>>> >>>
>>>
>>> >>> meeting password: Cite2010
>>>
>>> >>>
>>>
>>> >>> +1 512 225 3050 passcode:36429#
>>>
>>> >>>
>>>
>>> >>>
>>>
>>> >>> Luis
>>>
>>> >>> -------------
>>>
>>> >>> Luis Bermudez
>>>
>>> >>> lbermudez at opengeospatial.org 
>>>
>>> >>> +1 (301) 760-7323
>>>
>>> >>>
>>>
>>> >>> The OGC: Making Location Count...
>>>
>>> >>> http://www.opengeospatial.org/contact
>>>
>>> >>>
>>>
>>> >>>
>>>
>>> >>>
>>>
>>> >>> On Dec 9, 2010, at 1:50 PM, Luis Bermudez wrote:
>>>
>>> >>>
>>>
>>> >>>> All,
>>>
>>> >>>>
>>>
>>> >>>> On Dec 14th we are going to have a webinar at 10 AM eastern time
>>> to show case and discuss
>>>
> the latest work related to Client testing done by Chuck Morris from
>>> Northrop Grumman. Enclosed
>>>
> is the meeting information. I invite you all interested on this
>>> topic to participate.
>>>
>>> >>>>
>>>
>>> >>>> Topic: Client Testing
>>>
>>> >>>> Date: Tuesday, December 14, 2010
>>>
>>> >>>> Time: 10:00 am, Eastern Standard Time (New York, GMT-05:00)
>>>
>>> >>>> Meeting Number: 797 435 997
>>>
>>> >>>> Meeting Password: Cite2010
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>> -------------------------------------------------------
>>>
>>> >>>> To join the online meeting (Now from mobile devices!)
>>>
>>> >>>> -------------------------------------------------------
>>>
>>> >>>> 1. Go to
>>>
> 
>>> https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&PW=NOTcwMGQ5ZjFj&RT=MiM
>>>
> xMQ%3D%3D
>>>
>>> >>>> 2. If requested, enter your name and email address.
>>>
>>> >>>> 3. If a password is required, enter the meeting password: Cite2010
>>>
>>> >>>> 4. Click "Join".
>>>
>>> >>>>
>>>
>>> >>>> To view in other time zones or languages, please click the link:
>>>
>>> >>>>
>>>
> 
>>> https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&PW=NOTcwMGQ5ZjFj&ORT=Mi
>>>
> MxMQ%3D%3D
>>>
>>> >>>>
>>>
>>> >>>> -------------------------------------------------------
>>>
>>> >>>> To join the audio conference only
>>>
>>> >>>> -------------------------------------------------------
>>>
>>> >>>> +1 512 225 3050 passcode:36429#
>>>
>>> >>>>
>>>
>>> >>>> -------------------------------------------------------
>>>
>>> >>>> For assistance
>>>
>>> >>>> -------------------------------------------------------
>>>
>>> >>>> 1. Go to https://opengeospatial.webex.com/opengeospatial/mc
>>>
>>> >>>> 2. On the left navigation bar, click "Support".
>>>
>>> >>>>
>>>
>>> >>>> You can contact me at:
>>>
>>> >>>> lbermudez at opengeospatial.org
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>> To add this meeting to your calendar program (for example
>>> Microsoft Outlook), click this
>>>
> link:
>>>
>>> >>>>
>>>
> 
>>> https://opengeospatial.webex.com/opengeospatial/j.php?ED=148780447&UID=0&ICS=MI&LD=1&RD=2&ST=1&S
>>>
> HA2=d8QzvwbABa3sWVcIU1FluaZBcGcGHlsshXRzPqSTnC8=&RT=MiMxMQ%3D%3D
>>>
>>> >>>>
>>>
>>> >>>> The playback of UCF (Universal Communications Format) rich media
>>> files requires appropriate
>>>
> players. To view this type of rich media files in the meeting,
>>> please check whether you have the
>>>
> players installed on your computer by going to
>>>
> https://opengeospatial.webex.com/opengeospatial/systemdiagnosis.php
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>> http://www.webex.com
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>> IMPORTANT NOTICE: This WebEx service includes a feature that
>>> allows audio and any documents
>>>
> and other materials exchanged or viewed during the session to be
>>> recorded. By joining this
>>>
> session, you automatically consent to such recordings. If you do not
>>> consent to the recording,
>>>
> discuss your concerns with the meeting host prior to the start of
>>> the recording or do not join
>>>
> the session. Please note that any such recordings may be subject to
>>> discovery in the event of
>>>
> litigation.
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>> Luis
>>>
>>> >>>> -------------
>>>
>>> >>>> Luis Bermudez
>>>
>>> >>>> lbermudez at opengeospatial.org 
>>>
>>> >>>> +1 (301) 760-7323
>>>
>>> >>>>
>>>
>>> >>>> The OGC: Making Location Count...
>>>
>>> >>>> http://www.opengeospatial.org/contact
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>>
>>>
>>> >>>> _______________________________________________
>>>
>>> >>>> CITE.SC mailing list
>>>
>>> >>>> CITE.SC at lists.opengeospatial.org
>>>
>>> >>>> https://lists.opengeospatial.org/mailman/listinfo/cite.sc
>>>
>>> >>> _______________________________________________
>>>
>>> >>> CITE.SC mailing list
>>>
>>> >>> CITE.SC at lists.opengeospatial.org
>>>
>>> >>> https://lists.opengeospatial.org/mailman/listinfo/cite.sc
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> _______________________________________________
>>>
>>> >> CITE.SC mailing list
>>>
>>> >> CITE.SC at lists.opengeospatial.org
>>>
>>> >> https://lists.opengeospatial.org/mailman/listinfo/cite.sc
>>>
> 
>>>
> 
>>>
>>
_______________________________________________
>>
CITE.SC mailing list
>>
CITE.SC at lists.opengeospatial.org
>>
https://lists.opengeospatial.org/mailman/listinfo/cite.sc
>>
>> >
>>
_______________________________________________
>>
REST.SC mailing list
>>
REST.SC at lists.opengeospatial.org
>>
https://lists.opengeospatial.org/mailman/listinfo/rest.sc
>>
>>  
>>
>>
>> _______________________________________________
>> Architecture.dwg mailing list
>> Architecture.dwg at lists.opengeospatial.org
>> https://lists.opengeospatial.org/mailman/listinfo/architecture.dwg

> _______________________________________________
> REST.SC mailing list
> REST.SC at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/rest.sc


More information about the CITE-Forum mailing list