[cgi-prototype-users] each page is really an operation

[Terrence Brannon]

While I'm having my philosophical catharsis, I thought I would mention
that CGI::Prototype is actually not a page-based approach to site
development. It is an operation-based approach. An operation consists
of several phases which are broken down by CGIP nicely. We have model
phases and view phases. The view phases create a page based on the
requested *operation*.

A user requests *operations* - login, add user, view user which are
materialized by model actions and feedback on success failure via the
view/page.

If you take a look at Zanas:

http://search.cpan.org/~dmow/Zanas-5.5.16/Zanas.pm

he says a similar thing.

[A. Pagaltzis]

Post by Terrence Brannon
A user requests *operations* - login, add user, view user which
are materialized by model actions and feedback on success
failure via the view/page.

I model my applications as a set of resources, à la REST.

A GET request for `/user/12` brings up that user’s data. A POST
to the same resource will change his record. To receive the form
for editing a user record, you `GET /user/12?view=edit`. POSTing
to `/user/new` creates a new user resource, say `/user/42`, and
responds with a 302 redirect to that resource. (Actually, POSTing
always results in a 302, in order to make the browser’s back
button work and prevent accidental re-posts; but creating new
user resources would be a special case anyway.) Resources,
obviously, are only created or updated assuming credentials with
sufficient permissions; otherwise, the result is a 401 when not
logged in or a 403 when logged in, but lacking permission.

Etc.

This is the way HTTP was designed to work.

Regards,

[Terrence Brannon]

Post by A. Pagaltzis

Post by Terrence Brannon
A user requests *operations* - login, add user, view user which
are materialized by model actions and feedback on success
failure via the view/page.

I model my applications as a set of resources, à la REST.

I googled for REST and found this:
http://www.xfront.com/REST-Web-Services.html

Post by A. Pagaltzis
Resources,
obviously, are only created or updated assuming credentials with
sufficient permissions; otherwise, the result is a 401 when not
logged in or a 403 when logged in, but lacking permission.

Do you use cookies? The paper I read stated this:
<quote>
Stateless: each request from client to server must contain all the
information necessary to understand the request, and cannot take
advantage of any stored context on the server.
</quote>

To me, that means "no cookies". But your discussion of 401 and 403
would imply such a mechanism for recognizing who made the request?

[A. Pagaltzis]

Post by Terrence Brannon
To me, that means "no cookies". But your discussion of 401 and
403 would imply such a mechanism for recognizing who made the
request?

I do (still?) use cookies.

I’m still learning. :-) And several of my apps are already
modelled the “old” way. I’m rolling them over slowly.

Just two weeks or so ago I mentioned an URL `/edit/user/12` on
this list; now that is `/user/12?view=edit`, with the POST going
to `/user/12`.

I’ve found that following REST principles (even only partially)
has made the HTTP-side interface of my apps self-evident.
Previously, I guessed a lot. Now, the separations are obvious.
I like that.

401 vs 403 still holds, though – it would apply just the same if
I used HTTP authentication. (Ie no auth headers => 401, auth
headers for an account with insufficient permissions => 403.)

Regards,

[Terrence Brannon]

Post by A. Pagaltzis

Post by Terrence Brannon
To me, that means "no cookies". But your discussion of 401 and
403 would imply such a mechanism for recognizing who made the
request?

I do (still?) use cookies.

You are using a REST-inspired approach to web design, not pure REST:

<quote src="http://www.prescod.net/rest/state_transition.html">

REST basically advises you choose between these two strategies: send
all of the state back and forth (in this case using GET and URIs) or
capture parts of the state as resources with URIs and transmit links
to that state back and forth. What REST advises against is state
without a URI name. COOKIES ARE AN EXAMPLE OF UN-REST-LIKE DATA. Cookes
are implicit, so third parties have no access to them and even the
client application will not typically have any way to know what
cookies were in effect when a particular message was created hours
ago. REST stands for REpresentational State Transfer - the constant
transfer of state (or references to state) back and forth as
representations are key to its design.

</quote>

[A. Pagaltzis]

Post by Terrence Brannon
You are using a REST-inspired approach to web design, not pure

Yes. I never claimed otherwise; part of the reason for this is
that I’m writing plain old user-operated web apps, not (yet)
machine-operated XML-based web services.

And since I use cookies purely for authentication (see merlyn’s
article on how to use them), it won’t be very hard to switch to
a cookie-less modus operandi.

Regards,

[Terrence Brannon]

Post by A. Pagaltzis

Post by Terrence Brannon
To me, that means "no cookies". But your discussion of 401 and
403 would imply such a mechanism for recognizing who made the
request?

I do (still?) use cookies.

I think it is pragmatic that the first hit to a website be
cookie-based if possible.

What if you had to visit aristotle.perlmonks.org instead of simply
visiting perlmonks.org and having it authenticate you based on a
cookie?

Nothing but cookie-based recognition will ever fly in the corporate
world for the first hit.

[A. Pagaltzis]

Post by Terrence Brannon
What if you had to visit aristotle.perlmonks.org instead of
simply visiting perlmonks.org and having it authenticate you
based on a cookie?

You are forgetting HTTP authentication. You’d visit (in common
URI syntax) http://user:***@example.org/. REST does not preclude
authentication with its expose-resources-as-URIs approach.

Regards,

[Terrence Brannon]

Post by A. Pagaltzis

Post by Terrence Brannon
A user requests *operations* - login, add user, view user which
are materialized by model actions and feedback on success
failure via the view/page.

I model my applications as a set of resources, à la REST.
A GET request for `/user/12` brings up that user’s data.

This is what Paul Prescod lists as Common Design Mistake #3 when
building a REST website:

http://www.prescod.net/rest/mistakes/

<quote>
Do not depend on URI's internal structure. Some people think about
REST design in terms of setting up a bunch of URIs. "I'll put
purchase orders in /purchases and I'll give them all numbers like
/purchases/12132 and customer records will be in /customers..."
That can be a helpful way to think while you are whiteboarding and
chatting, but should not be your final public interface to the
service. According to Web Architectural principles, most URIs are
opaque to client software most of the time. In other words, your
public API should not depend on the structure of your URIs. Instead
there would typically be a single XML file that points to the
components of your service. Those components would have hyperlinks
that point to other components and so forth. Then you can introduce
people to your service with a single URI and you can distribute the
actual components across computers and domains however you want.
My rule of thumb is that clients only construct URIs when they are
building queries (and thus using query strings). Those queries return
references to objects with opaque URIs.

</quote>

[A. Pagaltzis]

Post by Terrence Brannon
This is what Paul Prescod lists as Common Design Mistake #3

I don’t expect clients to construct these URLs manually. Of
course they get there by following links from elsewhere on the
interface. The idea is to view URIs locations of a resource,
which can be manipulated by the appropriate HTTP verbs – as
opposed to viewing them as the name of a callable function.

See also:
http://www.intertwingly.net/blog/2005/03/09/Distributed-State-Machines

Regards,

[Randal L. Schwartz]

Terrence> While I'm having my philosophical catharsis, I thought I
Terrence> would mention that CGI::Prototype is actually not a
Terrence> page-based approach to site development. It is an
Terrence> operation-based approach. An operation consists of several
Terrence> phases which are broken down by CGIP nicely. We have model
Terrence> phases and view phases. The view phases create a page based
Terrence> on the requested *operation*.

Terrence> A user requests *operations* - login, add user, view user which are
Terrence> materialized by model actions and feedback on success failure via the
Terrence> view/page.

Yeah, even though I call them "page objects" in my head, I'm really
thinking of "operations", selected by the dispatcher, with each operation
able to "stay here" to redo a step, or "go somewhere else" to continue
in the interaction.