On 16/06/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > > > > > On Jun 14, 2007, at 5:34 PM, Steve Jones 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 > > > > If the client determines the URI, this would usually be a PUT to > http://example.org/customers/anne, otherwise a POST to http:// > example.org/customers. The server would the return the URI (POSTing > to a "collection resource" is a common pattern).
Fair enough, the PUT straight to the URI gives an interesting first filter, i.e. the challenge of "already exists" so overwriting something that shouldn't be. So I'm assuming there is no issue with outlawing PUT (within a system) on new resources and just using POST? > > > > GET http://example.org/customer/anne > > > > OK > > > > > GET http://example.org/customer/personByName?name=anne > > > > OK, although I would prefer http://example.org/customers?name=anne > (see, I *do* care about URI design ;-) ) I prefer that one too (I was just copying what came before). > > > > GET http://example.org/customer/personByAge?age=27 > > > > See above. > > > > > PUT http://example.org/customer/anne > > > > Fine for update as well as create. > > > > CREATE http://example.org/company/newco > > > > see above > > > > POST http://example.org/customer/anne?addCompany=http://example.org/ > > company/newco > > > > I'm not really happy with this one, I would prefer to do a POST to > http://example.org/companies/newco/employees (i.e. resource the > collection pattern from above). But that's probably a matter of opinion. I can see that, because the challenge is that both company and customer needs to be updated. > > > > > > 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 > > > > Yes > > > > > > and would it still be okay if then I could add filters > > > > GET http://example.org/company/newco/employees?name=anne > > > > Yes > > > > > > > Just checking if I still don't get REST :) > > > > You're definitely becoming used to it :-) Been playing more with it... but I still say its plumbing :) Steve > > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ > > > > > > > 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/ > > > > > > > > > > > > > > >
