Re: [rest-discuss] How to handle in a RESTful fashion?
----- Original Message -----
From: "Donald Ball" <dball@...>
> >You don't re-load the frame on the left, you use <form
> >> to reload the panel on the right.
> I take your point, if the thing on the left was a form with checkboxes,
> 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
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
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
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
> >> 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
> >> 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
> 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.