Loading ...
Sorry, an error occurred while loading the content.

OO REST Client Help

Expand Messages
  • pnruelle
    All, Can anyone give me some pointers as to how a REST client might be implemented in an OO language. To my mind there are two elements: 1) a collection of
    Message 1 of 3 , Jun 23, 2005
    • 0 Attachment
      All,

      Can anyone give me some pointers as to how a REST client might be
      implemented in an OO language.
      To my mind there are two elements:
      1) a collection of serializable classes which represent the resources
      2) a class which maps a given resource type to an URL

      There is an example on the web (http://ociweb.com/jnb/jnbNov2004.html)
      which works along these lines.

      However I have a few issues with this approach:
      1)Is it valid to map a resource type to a single URL or in practice
      would multiple URLs handle the same resource type?
      2) How could non-trivial GETs be specified? The example only shows
      GETs with a single valued key, but what about 'searches' on several
      non-key elements. What about searches using values of parent elements
      (in the example the 'owner' is effectively a parent value but it has
      been included in the child thereby circumventing this problem but I
      don't think that scales where you have deep hierarchies).
      3) Is there an application here for using "hypermedia as the engine of
      application state". Should there be a single entry point into the
      'application' and that then returns a list of valid links that can be
      called. This is the area of REST that I struggle with most and judging
      by the large number of articles that focus on resource exposure and
      addressing and the tiny number that cover this aspect of REST I guess
      other people do to.

      My approach is built on trying to keep the uniform interface within
      the OO client via the use of ResourceManager class which contains the
      4 CRUD operations and maps the resource types (specified by the class
      types) to URLs but perhaps that's not 'right'. We are talking about an
      OO client so maybe it is valid to wrap the REST interface into a SOAP
      style GetCollectionByOwner() interface even if it 'feels' wrong.

      Any and all comments, tips, hints, advice and anecdotes gratefully
      received.

      Regards,
      Phil
    • S. Mike Dierken
      ... Do you intend to transfer this serialized object to/from the resource? Or do you just mean an object instance for each identified resource? ... What s a
      Message 2 of 3 , Jun 23, 2005
      • 0 Attachment
        > Can anyone give me some pointers as to how a REST client might be
        > implemented in an OO language.
        > To my mind there are two elements:
        > 1) a collection of serializable classes which represent the resources
        Do you intend to transfer this serialized object to/from the resource?
        Or do you just mean an object instance for each identified resource?

        > 2) a class which maps a given resource type to an URL
        What's a 'resource type'? Do you mean a class like StreetMap, and it would
        have a 'constructURI' method that accepted an arbitrary set of parameters?
        Or maybe a strongly typed 'constructURI' method like:
        class StreetMap
        {
        String constructURI(String country,String state, String street);
        String constructURI(String latitude, String longitude);
        String constructURI(String dunsIdentifier);
        }


        >
        > There is an example on the web (http://ociweb.com/jnb/jnbNov2004.html)
        > which works along these lines.
        >
        > However I have a few issues with this approach:
        > 1)Is it valid to map a resource type to a single URL or in practice
        > would multiple URLs handle the same resource type?
        If 'resource type' is something like 'Employee' or 'StreetMap' or 'Product',
        then multiple URIs would be used - one URI for each instance of that
        resource type. For example, each of these resources are of type 'Product'
        http://www.amazon.com/exec/obidos/asin/B00003CXCT
        http://www.amazon.com/exec/obidos/asin/B0000AQS0F
        http://www.amazon.com/exec/obidos/asin/0940183218


        > 2) How could non-trivial GETs be specified? The example only shows
        > GETs with a single valued key, but what about 'searches' on several
        > non-key elements.
        You would just add those into the resource identifier - either as path
        segments or as query terms.


        > What about searches using values of parent elements
        > (in the example the 'owner' is effectively a parent value but it has
        > been included in the child thereby circumventing this problem but I
        > don't think that scales where you have deep hierarchies).
        I'm not sure what you mean.

        > 3) Is there an application here for using "hypermedia as the engine of
        > application state". Should there be a single entry point into the
        > 'application' and that then returns a list of valid links that can be
        > called. This is the area of REST that I struggle with most and judging
        > by the large number of articles that focus on resource exposure and
        > addressing and the tiny number that cover this aspect of REST I guess
        > other people do to.
        Yes, my opinion is that this works for small scale lists (1-10K elements),
        but larger ones may need 'chunking' via something like 'next' and 'prev'
        links in each resource representation.

        >
        > My approach is built on trying to keep the uniform interface within
        > the OO client via the use of ResourceManager class which contains the
        > 4 CRUD operations and maps the resource types (specified by the class
        > types) to URLs but perhaps that's not 'right'. We are talking about an
        > OO client so maybe it is valid to wrap the REST interface into a SOAP
        > style GetCollectionByOwner() interface even if it 'feels' wrong.
        There's nothing wrong with a GetCollectionByOwner() utility method within
        your client - but you'll end up with multiple implementations if you need to
        integrate with multiple providers. This will lead you to standardize on a
        'resource description language' in order to construct the URIs specific to
        each provider. Or, you may look into using the 'hypermedia' approach which
        has a 'GetCollections' utility method that returns a list of indivual
        Collection elements with an Owner attribute.
      • Phil Ruelle
        Thanks for the response. I did send a follow-up last week but I think I mistakenly sent it direct to Mike. Having given it some more thought I think what this
        Message 3 of 3 , Jun 27, 2005
        • 0 Attachment
          Thanks for the response. I did send a follow-up last week but I think
          I mistakenly sent it direct to Mike.

          Having given it some more thought I think what this boils down to is
          me trying to remove the whole URL scheme from the 'client' (by client
          I'm talking specifically of the business code that the developers will
          be writing) and create an object broker to act like an OR mapper but
          in this case it's an object-resource (representation) mapper.

          Has anyone done or considered anything similar? Or am I trying to put
          a square peg in a round hole?


          --- In rest-discuss@yahoogroups.com, "S. Mike Dierken" <mdierken@h...>
          wrote:
          >
          > > Can anyone give me some pointers as to how a REST client might be
          > > implemented in an OO language.
          > > To my mind there are two elements:
          > > 1) a collection of serializable classes which represent the resources
          > Do you intend to transfer this serialized object to/from the resource?
          > Or do you just mean an object instance for each identified resource?
          >
          > > 2) a class which maps a given resource type to an URL
          > What's a 'resource type'? Do you mean a class like StreetMap, and it
          would
          > have a 'constructURI' method that accepted an arbitrary set of
          parameters?
          > Or maybe a strongly typed 'constructURI' method like:
          > class StreetMap
          > {
          > String constructURI(String country,String state, String street);
          > String constructURI(String latitude, String longitude);
          > String constructURI(String dunsIdentifier);
          > }
          >
          >
          > >
          > > There is an example on the web (http://ociweb.com/jnb/jnbNov2004.html)
          > > which works along these lines.
          > >
          > > However I have a few issues with this approach:
          > > 1)Is it valid to map a resource type to a single URL or in practice
          > > would multiple URLs handle the same resource type?
          > If 'resource type' is something like 'Employee' or 'StreetMap' or
          'Product',
          > then multiple URIs would be used - one URI for each instance of that
          > resource type. For example, each of these resources are of type
          'Product'
          > http://www.amazon.com/exec/obidos/asin/B00003CXCT
          > http://www.amazon.com/exec/obidos/asin/B0000AQS0F
          > http://www.amazon.com/exec/obidos/asin/0940183218
          >
          >
          > > 2) How could non-trivial GETs be specified? The example only shows
          > > GETs with a single valued key, but what about 'searches' on several
          > > non-key elements.
          > You would just add those into the resource identifier - either as path
          > segments or as query terms.
          >
          >
          > > What about searches using values of parent elements
          > > (in the example the 'owner' is effectively a parent value but it has
          > > been included in the child thereby circumventing this problem but I
          > > don't think that scales where you have deep hierarchies).
          > I'm not sure what you mean.
          >
          > > 3) Is there an application here for using "hypermedia as the engine of
          > > application state". Should there be a single entry point into the
          > > 'application' and that then returns a list of valid links that can be
          > > called. This is the area of REST that I struggle with most and judging
          > > by the large number of articles that focus on resource exposure and
          > > addressing and the tiny number that cover this aspect of REST I guess
          > > other people do to.
          > Yes, my opinion is that this works for small scale lists (1-10K
          elements),
          > but larger ones may need 'chunking' via something like 'next' and 'prev'
          > links in each resource representation.
          >
          > >
          > > My approach is built on trying to keep the uniform interface within
          > > the OO client via the use of ResourceManager class which contains the
          > > 4 CRUD operations and maps the resource types (specified by the class
          > > types) to URLs but perhaps that's not 'right'. We are talking about an
          > > OO client so maybe it is valid to wrap the REST interface into a SOAP
          > > style GetCollectionByOwner() interface even if it 'feels' wrong.
          > There's nothing wrong with a GetCollectionByOwner() utility method
          within
          > your client - but you'll end up with multiple implementations if you
          need to
          > integrate with multiple providers. This will lead you to standardize
          on a
          > 'resource description language' in order to construct the URIs
          specific to
          > each provider. Or, you may look into using the 'hypermedia' approach
          which
          > has a 'GetCollections' utility method that returns a list of indivual
          > Collection elements with an Owner attribute.
        Your message has been successfully submitted and would be delivered to recipients shortly.