Adam Hardy wrote:
Jeromy Evans on 20/12/07 22:25, wrote:
http://my.company.com/myapp/rest/orders/1
All you're supposed to do is assign a unique URL to each resource,
which is exactly you've done.
Other important aspects of the approach are:
- you're binding the HTTP methods to certain operations (or in the
case of the REST plugin, certain methods in your action). eg. POST
does not return a result
- you're trying to maintain state only on the client (eg. you don't
use a session)
Trying to maintain state only on the client? How would you secure the
application?
That's the right question to ask.
I haven't used it in anger so I'm no expert, but people seem to argue
that REST over http can often just use the transport-level security
provided via http basic, http digest or ssl. Based on the REST APIs for
Google, Yahoo, Flickr, etc, though it seems the preference is for a
token generated at authentication-time that's included with every
subsequent request. The client doesn't need to know how the token is
accepted by the server (eg. the server can use a traditional session, or
a hash or some other mechanism hidden behind the service interface).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
