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

Fwd: [rest-discuss] Idea for a REST client

Expand Messages
  • Jan Vincent
    Sorry guys, missed the CC on this part. ... Jan Vincent Liwanag jvliwanag@gmail.com
    Message 1 of 1 , Feb 28, 2010
    • 0 Attachment
      Sorry guys, missed the CC on this part.

      Begin forwarded message:

      From: Jan Algermissen <algermissen1971@...>
      Date: February 28, 2010 5:17:54 PM GMT+08:00
      To: Jan Vincent <jvliwanag@...>
      Subject: Re: [rest-discuss] Idea for a REST client

      resend to list?


      On Feb 28, 2010, at 2:45 AM, Jan Vincent wrote:

      Could you perhaps point me to client implementations that are considered RESTful?


      Umm - no :-)

      I am working on the Jersey client side right now. Should be 1 or two weeks until it is good enough to show something.

      Jan



      Thanks,

      On Feb 28, 2010, at 9:20 AM, Jan Algermissen wrote:

      Jan,

      On Feb 28, 2010, at 1:17 AM, Jan Vincent wrote:

      I'm not sure again, why some knowledge of the state machine on the server would be a bad thing.

      It is bad because it couples client and server. This has the effect that the server owner needs to be aware of its clients to anticipate the impact of change. REST aims to eliminate that coupling.

      The idea I have is something like that of a user browsing through different pages of a website, the difference being is that it is based on some script. Should the server decide to deviate from that script, then yes, things would be screwed up.

      Yep - and REST focusses on the server being able to change without things screwing up. This can only be achieved if the client adheres to the hypermedia constraint. Meaning that the client must look at any steady state (that it is being put into by the server) how to proceed to achieve its overall goal. The client must only decide this based on the current steady state after having reached it.


      As such, the content-types provide some form of contract that some elements would need to exist on the representations the restful service serves.

      But the client must not make any design time assumptions about the content type it will actually receive.

      In the example provided below, I assume the presence of certain links, and some forms I could fill out.

      The hypermedia constraint forbids such assumptions.

      This is of course not to say that clients that make such assumptions cannot be appropriate for a given set of requirements. But it is important to understand that the system you end up with is not RESTful because client and server are coupled around these assumptions.

      In my opinion, RESTful systems have two essential benefits: Simplicity and eliminating the need for service owners to communicate with client owners when they intend to change the service to support some previously unanticipated requirement (think "business agility").

      Simplicity is a huge benefit in itself and achieving it does not depend on adhering to the hypermedia constraint (see my HTTP-based Type I/II). However, being able to evolve the components of a complex system (think "The Web" or "enterprise integration") at an independent pace easily justifies the effort of building a truly RESTful system.

      Jan


      I don't really care about the format of the URL, and to some extent, even the methods (since I simply fill out forms on the xhtml representation).

      Moreover, I liken what I have described below as something like tabbed browsing by some user. The user, goes on to the main site, clicks on the lists of users, fills in a form to search for some user and then clicks on the result. If another search is needed, a new 'tab' is opened to save the old resource (say, the setting on the browser is to open the same page on the former tab), hit 'back' to the search users form, and search again.

      On Feb 27, 2010, at 9:21 PM, Jan Algermissen wrote:

      Jan

      On Feb 27, 2010, at 10:15 AM, Jan Vincent wrote:



      Hi guys,

      I wish to create a framework for accessing REST resources over HTTP. I wish to focus on xhtml Content-Type in particular. The idea is that the developer would provide instructions on how to get to the resource from a single URL.

      Implementation-wise however, the framework would provide all the necessary plumbing to take care of caching and what not.

      Consider three resources:

      Root Resource - primary URL ("/"), entry point for the service, has a link to the User List
      User List - lists all users, on GET, may accept a query string "email" to search for a specific user, contains link to the users' respective profiles
      User Profile - the profile of a user

      In order to implement something like get_user_by_email, the developer would have to describe how to get from the Root Resource to the User Profile. In code, a developer using the framework would do something like:

      get_user_by_email(email) {
      from("/")
      .on(200) { |Root|
       Root.follow("#users_link")
         .on(200) { |Users|
           Users.fill_in("#search_form", {"email": email})
             .on(200) { |SearchResult|
                SearchResult ...get_first_result...
                  .on(200) { |Profile|
                    return profile_to_some_struct(Profile)
                  }
             }
         }
      }
      }

      I'm still working on how to best express this intent as code, and it's pretty ugly now I must admit.

      The problem (from a RESTfulness POV) with this is that the code assumes a certain state machine of the application. If the server decides to change that state machine, the code will break.

      If the service publishes information that allows the client to make such assumptions as manifested by the code above, the service is not RESTful but is an "HTTP-based Type I" <http://nordsc.com/ext/classification_of_http_based_apis.html#http-type-one> (or "HTTP-based Type II") API.

      If the server does not publish such information the code above just represents guess-work which would be worse because the coupling would actually be hidden inside the code.

      When you think about such a framework approach, keep in mind that it will lead to tightly coupled systems no matter how "Webby" the system looks. If the service evolves, the client will break.

      Whether this is actually a bad thing depends on the requirements - maybe long term evolvability has been traded for getting something started fast and maybe the expected system lifetime is so short that evolvability does not matter, but you need to be aware of this to make an informed decision.

      Jan





      However, the framework doesn't really execute the instructions by the developer directly. Instead, it uses its built in cache to get the result. From the example above, the framework would do things in reverse:

      1. Is there a cache* of the result to a call to get_user_by_email(email)? If YES, return prior result, If NO, go to step 2
      2. Is there a cache of the result to a call getting the search matches of a user given a specified email? If YES, using that result, go down the code -- following the link to the user profile, then returning the result. If NO, go to step 3.
      3. Is there a cache of the list of users? If YES, go on and fill in the search form, etc. If NO, go to step 4
      4. Is there a cache of the root resource? If YES, go back steps 3,2,1. If NO, get the root resource, and then go further back the steps.

      * When I say cached, I generally mean that there has been a prior call, and the result was cached AND the cache hasn't expired yet based on the server cache instructions

      The framework forms a tree of possible scenarios. It starts from the most optimistic test (step 1) on the leaf, and if it fails, goes back to its parent.

      I believe this would be useful especially if the applications that are going to be built don't follow the UI style of web pages following linked documents. Is this a HATEOAS respecting client? I'd truly appreciate some inputs.

      FYI, I'll start development of an Erlang version at http://bitbucket.org/jvliwanag/restr/ . Though, there's nothing there yet now. Hehe.

      Jan Vincent Liwanag
      jvliwanag@...







      -----------------------------------
      Jan Algermissen, Consultant
      NORD Software Consulting

      Mail: algermissen@...
      Blog: http://www.nordsc.com/blog/
      Work: http://www.nordsc.com/
      -----------------------------------





      Jan Vincent Liwanag
      jvliwanag@...




      -----------------------------------
      Jan Algermissen, Consultant
      NORD Software Consulting

      Mail: algermissen@...
      Blog: http://www.nordsc.com/blog/
      Work: http://www.nordsc.com/
      -----------------------------------





      Jan Vincent Liwanag
      jvliwanag@...




      -----------------------------------
      Jan Algermissen, Consultant
      NORD Software Consulting

      Mail: algermissen@...
      Blog: http://www.nordsc.com/blog/
      Work: http://www.nordsc.com/
      -----------------------------------





      Jan Vincent Liwanag



    Your message has been successfully submitted and would be delivered to recipients shortly.