On Mon, 2006-12-11 at 13:35, Steve Jones wrote: > On 11/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote:
> > I think I finally get the disconnect here. Steve's trying to put the > > client in control and REST (as Jan explains pretty well) is about > > putting the service in control. I think this is important, and I also > > think this is why SOA is better than what we've had before. > > Not quite, the Service is in control of what it does has always been > my view. But the value of the service is only realised when it is > invoked by a consumer. Hence the reason why you should design > interfaces with clients, not services, in mind. > http://service-architecture.blogspot.com/2006/07/consumers-view-of-service-description.html Amusing post (I laughed), but it isn't what I'm talking about. Since we've mentioned Amazon, let's look at this scenario and see if I can explain what I mean. If you were to describe Amazon in 2 min as a service interface, you might get something like: Bookseller - findBooks - findBooksMatching - viewBook - addToCart - placeOrder There's more, but this is enough. The way I understand a REST approach to providing this service you'd have something like this (data-types aside; as I mentioned, that's a different discussion): Step 1: GET amazon.com This returns an HTTP 200 response code and an HTML+Form response with a bunch of links. What you can do: - follow a link to view an item - follow a link to view items within a pre-selected category - enter search times to find items that match your search criteria - follow a link to view the contents of your cart - follow a link to view your account settings Now, I'll admit there's some processing involved to determine that the view and item link and the contents of cart links are different, but if you follow them (do a GET), you should "recognize" the representations (more on this in a minute). Step 2: follow a link to view an item (GET the URI) This (best case) returns an HTTP 200 status code an another HTML+Form response that happens to be something that you recognize (or maybe it's an XForms XML document whose data model's root element corresponds to the AmazonItem schema and it contains references to submit actions for 'add to cart'. I'm not sure if this is right, but why not?) What you can do here is: - follow a link to view an item - follow a link to view items within a pre-selected category - enter search times to find items that match your search criteria - follow a link to view the contents of your cart - follow a link to view your account settings - add the item to the cart with the submission of a form operation - complete the order with a machine equivalent of 'one-click order' based on knowing your identity. This is the answer to your earlier question about how do you represent compliance steps or whatever needs to happen during the interaction. It's all about what you expose to the client as available options *at each step of the process* that directs the client to "do the right thing" or at least "do *one* of the right things" for a given step in the overall interaction. I could go on with more steps, but it wouldn't prove much. The thing is that the available operations to the client at any time t varies depending on the client's current position within the application state machine provided by the service. State traversal can only take place using one of the HTTP operations, but the implications of those state transitions come from the interpretation of the hypermedia document exposed to the client at time t. At time t+1, the options could be different (maybe you can have your items beamed to your home rather than shipped via UPS). If you understand what "beam my items" means, great. If not, you still pick the "ship it" option of the choices the way you did at time t, and everything still works. The people whose client understands Star Trek transporters just get their items a little bit quicker. :) This type of dynamic, service-controlled interaction is what I do think isn't part of any WS-* system I've ever seen (or CORBA, or EJB or any programming API on the planet). It's still testable because you are testing what you can detect, interpret and how your client can prepare the data necessary for POST or PUT operations, but you're agreeing and testing capabilities and semantics rather than invocation and you don't have to know anything more about when to invoke an action other than "you can only do it if you see it in front of you". Does this make sense? I truly see there's a difference here, but it might be difficult to see if you only focus on the words or the individual parts. The above example is about what I meant about "the server is in control of the interaction". > > > > Steve mentioned BEPL in one of the other mails, but until this one, one > > of those fundamental assumptions I was talking about before didn't hit > > me. > > > > Without re-starting the orchestration vs. choreography thread again, > > traditional programming puts the API client in charge of taking the > > steps to complete a particular business process. It needs to know the > > API, what order to call them and what parameters to pass in, but the > > server always exposes the same functionality to all clients via this > > API. > > I think of BPEL as an implementation language OF service, rather than > something distinct. > > > > > With REST, this isn't the case. The server is in control of the > > interaction, not the client. The client is an active participant and > > always has an option of stopping the conversation at any point, but the > > server is responsible for maintaining the application state internally > > (but it may push the storage of that state information out to the client > > and not manage it itself). > > Not sure how this is different to any standard system of the last 30 > years. A database could make the same claim. > > > > > REST is more like eating a set dinner rather than ordering off a menu. > > Traditional programming is always about ordering al a carte. This is > > part of the shift in perspective that's required to successfully build > > systems using the REST architectural style. > > Again this has nothing to do with REST, ERPs are about the set dinner > as well, and I've always argued that dictate is the best way to get > stuff done. Most projects I've ever done have dicated the format and > the approach, this works. REST isn't inventing anything new here. But they're still APIs that you need to understand how to choreograph to achieve what you want to do. > > > > On the other hand, Steve also has some good points about the agreement > > of data models between parties. Part of why the Web works is because > > HTTP, Forms and HTML are everywhere, but to encode something outside of > > that space requires additional agreements. There are ways to do this, > > e.g. UBL, but they aren't as ubiquitous as HTML+Forms. Atom will help, > > but only partially. However, the inversion of control aspect of REST > > and the definition of the messages exchanged are two separate issues. > > The "inversion of control" as you call it is not news, I've always > argued on standardisation and dictat for interfaces and on the drive > towards vanilla except where it actually differentiates. So REST (for > me) doesn't offer anything new. No, the concept isn't new, but the way in which it manifests itself seems to me to be. > The definition of the exchange should be done from the perspective of > the "many" however rather than the "few", if you have a server centric > interface it will be less usable than one that hides the nasty bits of > the server from the clients. This doesn't mean that clients dicate > anything, it just means that you have a strong design. My question > with REST is around the exchange as you say, and I'm struggling to see > how REST is an advance over old ways, it sounds too much like old > "techy knows best" approaches that I've seen on projects over the > years. I tried to explain this above. Maybe I still haven't made it clear, but it's at least clearer to me right now than it was last week. I can keep trying though if you like... ;) ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
