On 11/30/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > As an architectural style, REST is limited in the kinds of constraints > > it can define; if it's not a constraint on a relationship between > > software architectural elements (data, connectors, components), it's > > not in play. That leaves lots of room for best practices which have > > nothing to do with REST. > > So as a question (and back to the idea of method invocation v > resource) how would an invoice summary for a series of dates be done > in rest world? Would it be done by having (in Stefan's URI) > > http://www.frood.com/customer/invoice/summary > > and passing in an XML document that contains the dates,
That could be done, and would be RESTful. > or would a > parameterised approach that enables an HTML style submission be > allowed (i.e. ?startDate=10/10/01&endDate=10/10/06). If the later > then could a full parameterisation of > customer?type=invoice&request=summary be classed as being REST. Sure. There are advantages to the latter approach though, in particular that you can hand that URI to any person or HTTP automata on the planet and they'll also be able to get the data. That's not the case with the former approach because the client needs to know the data format to POST. > The reason I'm asking is that requesting a summary of invoices is a > pretty common thing that requires calculation and aggregation on the > server. My, naive, view on REST would be that the parameterised > approach is acceptable, and even the fully parameterised element seems > to be okay. The problem I'm wrestling with is why this isn't just a > command pattern implementation using URIs. You mean the "request=summary" bit? I wrestled with that issue for years too. The answer is because it's opaque to clients - not part of the shared contract between client and server - unlike if it were a command. Mark.
