"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: 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> -- 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 cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
