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

Re: [rest-discuss] How to handle in a RESTful fashion?

Expand Messages
  • S. Mike Dierken
    ... From: Donald Ball ... but ... Use a hidden frame with a form to send control messages. The onClick for the link calls script that
    Message 1 of 6 , Oct 28, 2002
    • 0 Attachment
      ----- Original Message -----
      From: "Donald Ball" <dball@...>

      > >You don't re-load the frame on the left, you use <form
      > target='panel_right'
      > >> to reload the panel on the right.
      >
      > I take your point, if the thing on the left was a form with checkboxes,
      but
      > UI constraints dictate that it's an explorer tree with links. c'e la vie.
      Use a hidden frame with a form to send control messages. The onClick for the
      link calls script that submits a non-visible form in a zero or one pixel
      high frame. This can be used to communicate with the server without bumping
      into UI/presentation issues.


      >
      > So you're of the opinion that, given the design constraints, it would be
      > preferable to massage the requests to POSTs using javascript than to issue
      > GET requests without relying on javascript?
      If doing a GET modifies data on the server, then I would use POST - even if
      that means using script on the client.
      What happens if the user clicks the same link twice?
      How does a user remove the column name from the view?
      What happens when a spider crawls the link?
      What happens when a user bookmarks a link or drags the link to their
      desktop?
      What does the user see when they click link A, then link B, then link A? The
      second time they click link A they won't see the same as the first time they
      clicked on link A - it'll look like they are still on link B.

      >
      > unless the semantics for the /view URL dictate that, absent a specific
      > identifier, the current view for the user is the one being modified. Is
      > that legit from a REST pov?
      No. The resource identifier should identify the same resource for all
      clients.
      If you generate the HTML for the tree control with href= links that have the
      userid in a query term, then that isn't a problem.
      It makes the HTML slightly larger though.

      >
      > >> 1. I'm not specifying the view id in the change request. Due to the
      fact
      > >> that I don't want to regenerate the link tree, though, this is largely
      > >> unavoidable. I'll just store the user's active view id in their
      session,
      > >> but always redirect them to a URL which they can use absent a session.
      > >Tell me again why using a viewId causes the tree to change?
      >
      > because I don't know the view id until the user has created one by
      clicking
      > on a link in the tree. It would be undesirable for a couple of other
      > reasons as well, actually.
      What about always having a view ID for each user - even if it is empty.
      The tree would always have that URI in the href= links.


      > So the upshot seems to be that, given my constraints, the links in the
      > explorer should silently turn into POST requests, which send back 303
      > redirects to a long-lived URL for the dataset view. I can live with that,
      > thanks for the conversation.

      No problem. But this conversation is like many I've had when designing
      systems in the past.
      It's also very indicative of why I believe that REST based resource
      modelling is best suited for 'automation' based Web systems and classical UI
      based systems with existing browsers & server technology just run into too
      many issues that are counter to good REST based design. Essentially I
      believe that usability requirements (projected onto browsers and their use
      of HTTP) conflict with REST principles projected onto HTTP.

      So, it's okay to strive for RESTfulness with HTML and browsers, but don't
      sweat the (sometimes major) conflicts that are going to pop up.
    Your message has been successfully submitted and would be delivered to recipients shortly.