"A. Pagaltzis" <[EMAIL PROTECTED]> writes:
> * Terrence Brannon <[EMAIL PROTECTED]> [2005-09-03 19:15]:
>> 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:
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.
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
cgi-prototype-users mailing list