I have several use cases that I do not believe fit into the REST style.
I'd be interested in being enlightened:
Use case 1 (The conventional business cycle)
A supplier S and a customer C:
C places an order with S (which may involve many too-ing and fro-ing,
but let us stipulate for the moment that it can be modeled as a series
of invocations of web services)
Sometime later, at a time determined by S, S sends a delivery note to C
noting (sic) that the product has been shipped
Sometime later still, also at a time determined by S, S sends an
invoice. (BTW its not reasonable to assume that C has any motivation to
poll S for the invoice)
Later still, S sends an aged balance statement. Again, C has no
motivation to poll S for this.
Eventually, C sends a remittance advice note to S. Again, S is too busy
to poll C for it, and C being a large corporation and S being a mom'n
pop shop would not look too kindly on all this polling.
Currently, our best thoughts are that you need two web service centers;
one belonging to S and one belonging to C. In addition you need two user
agents. However, you now have a massive coordination and identity
problem since, at the level of business relationships, the web
service/user agent pairs are implementation artifacts that obscure the
fact that there is a single entity behind each. This architecture also
obscures the interrupt-driven style of the use case -- what method on a
customer server is being invoked when a supplier delivers its age
balanced statement?
The other use case is even more entertaining, which I'll leave for
another challenge.