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

Pat Cappelaere pat at cappelaere.com
Thu Dec 16 09:54:41 EST 2010


John,

I would not describe the state of the server as changing.  Individual resources or collection may change and that is easy to test via etags and last-modified.
Pat.

On Dec 16, 2010, at 9:08 AM, John Herring wrote:

> Pat,
>  
> The point that Ethan and I both was probably best stated by Ethan:
>  
> 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.
>  
> In other words, the test described by Philippe while important, is not a complete description of the testing environment. A RESTful service that allows any PUT, POST or DELETE from a client under any circumstance changes the resource graph that Philippe’s test traces. For example, a WFS-T (transactional web feature service) may allow features to be completely replaced by a PUT or partially updated by a POST. New features might be added to the collection by using a POST. Each of these operations  changes the state of the service, probably for everyone.
>  
> The question was never “if a RESTful service could be tested” but how could a “RESTful service standard might be written to facilitate conformance testing and instrumentation of 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
>  
>  
> From: Pat Cappelaere [mailto:pat at cappelaere.com] 
> Sent: Thursday, December 16, 2010 7:47 AM
> To: John Herring
> Cc: 'Philippe Duchesne'; architecture.dwg at lists.opengeospatial.org; cite.sc at lists.opengeospatial.org; 'Arnulf Christl'; rest.sc at lists.opengeospatial.org; cite-forum at lists.opengeospatial.org
> Subject: Re: [Architecture.dwg] [REST.SC] [CITE.SC] Resource Oriented Architecture
>  
> I have still not clue about the problems you are raising.
> I hope that I am not hearing the implications that connections are stateful.  This would defeat the purpose of a RESTful architecture. 
>  
> Of course, a RESTful service is not static.  People continuously publish new data on the web. It is very easy to detect that new resources have been added to a feed.
>  
> Can you bring up a real use-case showing that a RESTful system cannot be tested?
>  
> Pat.
>  
> On Dec 16, 2010, at 4:30 AM, John Herring wrote:
> 
> 
> Philippe
>  
>           This took me a bit, because it is right as far as it goes. What you suggest is in fact how we can verify that a set of web resources is properly structured according to a specification. This is obviously an important part of the “conformance” inspection for that part of the implementation that depends on static resources. That part consists of all the “representation[s] that contain… all the hyperlinks that [they are] supposed to have.” That process traces all the pertinent static resources, but is does not get much beyond what GET-based crawler can do in a static structure. A “service” is by its nature not static.
>  
> Use of “POST,” “PUT” and “DELETE” (and possibly other parts of the HTTP static interface) can change that structure, as Ethan Davis puts it “there will be times when it is important to test that the server's state changes upon the proper requests from an authorized client.”  For example, today’s WMS depends solely on a “RPC” style GET, but in a RESTful implementation, the user should not have to know how to construct the URL used in this GET; the mechanism to construct it should be a predictable sequence of PUTs and POSTs. Ditto for WFS, where construction of a query (as a resource) may be separate from its execution.
> Regards,
> John
> One of the defects of all philosophers since Plato is that their inquiries ... 
> proceed on the assumption that they already know the conclusion to be reached.
>                                  -- Bertrand Russell, History of Western Philosophy, 1946
>  
> 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
> 
> 
>  
>  
> From: architecture.dwg-bounces+john.herring=oracle.com at lists.opengeospatial.org [mailto:architecture.dwg-bounces+john.herring=oracle.com at lists.opengeospatial.org] On Behalf Of Philippe Duchesne
> Sent: Wednesday, December 15, 2010 11:21 AM
> To: John Herring
> Cc: 'Pat Cappelaere'; architecture.dwg at lists.opengeospatial.org; cite.sc at lists.opengeospatial.org; 'Arnulf Christl';rest.sc at lists.opengeospatial.org; cite-forum at lists.opengeospatial.org
> Subject: Re: [Architecture.dwg] [REST.SC] [CITE.SC] Resource Oriented Architecture
>  
> 
> 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.
>  
> How do you state testable requirements on a RESTful application in an OGC implementation standard?
> 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)
> > 
> > -----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
>  
>  
>  
> _______________________________________________
> Architecture.dwg mailing list
> Architecture.dwg at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/architecture.dwg
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/cite-forum/attachments/20101216/f1f33251/attachment-0001.htm>


More information about the CITE-Forum mailing list