Steve, HTTP does not have a CREATE method. New resources are creating using either POST or PUT depending on whether the client or the server specifies the URI. If the server creates the URI, you use POST. If the client specifies the URI, then you use PUT. So the methods would be more like this:
POST http://example.org/customer HTTP message body contains a representation of "anne" server creates a subordinate resource called http://example.org/customer/anne GET http://example.org/customer/anne returns a representation of "anne" GET http://example.org/customer/personByName?name=anne returns a representation of "anne" or perhaps returns the URI of the "anne" resource or perhaps returns a list of URIs of all people named "anne" might also be specified more simply as GET http://example.org/customer?name=anne GET http://example.org/customer/personByAge?age=27 returns a list of URIs of people whose age is 27 or perhaps returns a collection of representations of all people aged 27 might also be specified more simply as GET http://example.org/customer?age=27 PUT http://example.org/customer/anne HTTP message body contains a representation of "anne" either creates a new resource called "anne" (if none exists) or replaces the existing "anne" resource PUT http://example.org/company/newco HTTP message body contains a representation of "newco" either creates a new resource called "newco" (if none exists) or replaces the existing "newco" resource If you prefer the server to assign the URI you would instead say POST http://example.org/company HTTP message body contains a representation of "newco" server creates a subordinate resource called http://example.org/company/newco POST http://example.org/customer/anne?addCompany=http://example.org/company/newco this would append the newco company reference to the "anne" resource Anne On 6/14/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > > I'm liking the non-opaque RESTful URIs BTW :) I makes it so much > easier to understand :) > > A small question here > > CREATE http://example.org/customer/anne > GET http://example.org/customer/anne > GET http://example.org/customer/personByName?name=anne > GET http://example.org/customer/personByAge?age=27 > PUT http://example.org/customer/anne > CREATE http://example.org/company/newco > POST > http://example.org/customer/anne?addCompany=http://example.org/company/newco > > Would that by a RESTful set of calls that create anne, do some finds, > create a company and assign anne to the given company? Clearly the > last POST could also be a PUT, but lets assume for a moment that the > customer XML doc is 100k and we don't want it all streaming over the > wires. In addition would the following be okay if it returned the > full list of employees for a given company > > GET http://example.org/company/newco/employees > > and would it still be okay if then I could add filters > > GET http://example.org/company/newco/employees?name=anne > > Just checking if I still don't get REST :) > > > On 14/06/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On Jun 14, 2007, at 2:14 PM, Anne Thomas Manes wrote: > > > > > Let's say for example you have a service that manages information > > > about people. A service-specific interface would expose interfaces > > > like: > > > > > > person getPersonByName("anne") > > > > > > person[] getPeopleByAge("29") > > > > > > and a service-specific POX representation of these methods would be > > > something like: > > > > > > GET http://example.org/getPersonByName?name=anne > > > GET http://example.org/getPeopleByAge?age=29 > > > > > > A RESTful interface would be more like this: > > > > > > GET http://example.org/people/anne > > > GET http://example.org/people?age=29 > > > > You might want to avoid using GET as an example, because from a REST > > point of view > > > > > GET http://example.org/getPersonByName?name=anne > > > > and > > > > > GET http://example.org/people/anne > > > > are equally RESTful (although the first one is so by accident). Using > > something like GET /application?operation=createPerson&name=Anne > > makes it a little clearer. > > > > Stefan > > -- > > Stefan Tilkov, http://www.innoq.com/blog/st/ > > > > > > > >
