[CITE-Forum] [REST.SC] [CITE.SC] Resource Oriented Architecture (was: Re: Dec 14th Client Testing Webinar)

Pat Cappelaere pat at cappelaere.com
Wed Dec 15 09:55:51 EST 2010


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)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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
> 
> 
> - --
> Nothing makes sense, except we make it.
> http://www.metaspatial.net
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAk0Itw4ACgkQXmFKW+BJ1b0sYgCfVxkjkUuwz6ew/5AZ2s7BUgzv
> JJcAn1IfRgaovhT7CSPavu1PQt9sMLuW
> =XF4x
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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



More information about the CITE-Forum mailing list