On 11/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > > > > 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):
So its taken you 9 lines to describe the service interface... > > 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. And quite a bit more to describe it in REST. Now you can argue that you've allowed more flexibility in the REST interface, but you've also got a lot more complexity. > > 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". So you are saying that this is simpler than having a schema change on the "placeOrderRequest" which includes the new shipping option? I'm not seeing that. Also the arugment here appears to be for continuous process rather than more dynamic goal oriented things, I might not see something in front of me but why can't I just go somewhere else to do it? This sounds like for REST you should always do a GET before a POST or PUT, rather than caching the last GET as that might not be valid anymore. > > 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". And I'm with that as a theory, but I don't see how REST is better than WS at this stage. Like I said I've always said that what is behind the service stays behind the service. But saying that process can _never_ be fixed is a bit odd when you look at things like invoicing and receipting which haven't changed in 100 years or so, why would it be bad to save time by hard-wiring that? > > > > > > > > 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. Which is the same as REST, REST doesn't stop me having to understand what I want to achieve, nor does it stop me having to understand what the server enables me to do in order to achieve my goal. I'm clearly missing something, but I can't see what it is. > > > > > > > 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. But not for me, nor I'd say for people who put in ERP solutions, go and ask SAP what the best way to do things is.. the answer will be "our way". > > > 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. The thing is I think I get the mechanism of REST now, I just don't see why I'd want to do it, and I _really_ don't see how its simpler to use for developers and support folks. > > I can keep trying though if you like... ;) Hey its better than working.... > > ast > -- > Andrew S. Townley <[EMAIL PROTECTED]> > http://atownley.org > > > >
