On 10/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > > On Dec 10, 2006, at 8:49 PM, Steve Jones wrote: > > > > > So it is impossible in REST to say that fraud detection must be called > > before credit card processing > > The server is in complete control of what may be called when by whom. > It only needs > to provide the state transitions (the calls) at the appropriate time.
Can you please answer the question. Is it possible or impossible? > > (Picture an HTTP representation as a fragment of the current state > machine that is > exposed to the client. Or picture a candy machine that only lets you > choose candy > AFTER you inserted a coin. (Google Robin Milners CCS on this - > interesting read.) Which is fine for a physical machine, but with REST we have the CreditCard URI for the CreditCard resource and the FraudDetection URI for the FraudDetection resource. What happens if I call the CC URI before the FD URI? What tells me that I should do one before the other? > > > > > "link semantics" this is a term that is being bandied about alot with > > out much backup. What describes the MEANING (not the syntax set or > > ontology ala MIME) of a link? > > After a GET on ttp://example.org/edit/first-post.atom > you get: > > HTTP/1.1 200 Ok > Date: Fri, 7 Oct 2005 17:17:11 GMT > Content-Length: nnn > Content-Type: application/atom+xml; charset="utf-8" > > <?xml version="1.0"?> > <entry xmlns="http://www.w3.org/2005/Atom"; > xmlns:app="http://purl.org/atom/app#";> > <title>Atom-Powered Robots Run Amok</title> > <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> > <updated>2003-12-13T18:30:02Z</updated> > <author><name>John Doe</name></author> > <content>Some text.</content> > <link rel="edit" > href="http://example.org/edit/first-post.atom"/> > </entry> > > What do you need to do to find out what the <link> means? 1) What the word "edit" means 2) The format of the schema for the "edit" request 3) The format of the response from the "edit" request. If I'm a computer the word edit (as per the opaque discussion) means nothing. Certainly application/atom+xml tells me nothing about the MEANING of the content. > > > > > > > > >> (You can experience that way of doing things everytime you buy a > >> book > >> at Amazon - would you care if Amazon changed the order of pages you > >> proceed through? Would you even notice?). > > > > To rephrase, if Amazon allowed shipping to commence before payment > > would you notice... err yes I would and I'm pretty sure they would > > too. > > yes. So you agree that we both would notice the order of pages, and we indeed care about the order of pages? > > > > >> > >>> and that people can't even agree on the "right" definition for a > >>> URI. Its fine to _claim_ that something requires a new way of > >>> thinking but having read the REST paper (and various other works) > >>> I'm not seeing much different (architecturally) over the Unix pipes > >>> solution of the late 80s & early 90s. Just because something moves > >>> over a standard port doesn't (IMO) make it special. > >> > >> What I constantly do not understand is why people take such a > >> negative position against REST - as if it is something hostile to > >> suppress.... > > > > > > Nope, I'm just asking questions that don't get answers (or get several > > contradictory answers). I'm not hostile against REST anymore than I'm > > hostile against any other silver bullet technology. REST does certain > > things, but I've yet to see the "magic" that is proposed, this is > > probably because I'm a bit dense, but I'm coping admirably with my > > stupidity. > > See my last post, maybe that answers some questions? Nope. > > > > > > >> > >>> > >>> Saying "the Web is different" is a fairly glib statement if it > >>> can't be backed up with "why". So far the advantages I've seen > >>> with REST in terms of simplicity have been stripped away when you > >>> actually ask for the simplicity to be defined. > >> > >> Maybe give the dissertation another close read...? It is really all > >> in there and also quite clear - once you have built up the > >> background > >> knowledge (at least that was my perception). > > > > I'll try again, but it doesn't include application interface > > formalisation or the URI bits which I'm asking about. The devil with > > any proposal is in the detail, REST is (IMO) lacking in that detail. > > The devil with REST is to provide people with the Howtos because the > overall picture is appearently too open to apply REST. > > Adding Atom to the list of pervasive standards (HTTP+URI+ATOM) > IMHO helps a lot because it narrows down the things one has to > decide upon. ATOM, as per the other post, provides an envelope, it does not provide the content. Application interfaces include the content as well (which you proposed UBL for). > > > > >> > >>> > >>> At the moment I see a massive hype around REST which doesn't take > >>> into account the engineering disciplines of the last 30 years and > >>> which appears to being pushed as a magic bullet. Lets be clear, > >>> I've used MQ, CORBA, RMI, WS-* (.NET and Java), custom, Unix pipes, > >>> ftp, shared directories and other mechanisms in commercial > >>> projects, and I've only played around with REST, and every single > >>> one of them has issues and advantages technically. > >> > >> So what? All people are saying is that (1) REST is superior to > >> SOA/WS- > >> * for the problems that WS-* set out to solve and (2) that WS-* is > >> likely to reinvent REST in order to solve the problems it is trying > >> to solve. > > > > 1) lets split SOA from WS-*, the aren't the same thing. A resource > > (data) based view of enterprise modelling is IMO a weak one, but that > > isn't a WS-* v Rest debate. > > Do you mean by that a functional view is better and that SOA > emphazises the > functional view? Nope, I mean that a behavioural view is better (function + data + state + goal) > > > > > 2) Have a look at that Danish example where the folks at WS02 are > > "struggling" with WSDM interop with .NET/Java.... and point me to the > > bits of REST that would help them. > > Will do (when time provided) > > > > > 3) You do know that there are lots and lots of successful commercial > > WS-* implementations. > > The issue here is what "successful" means. > > (Are they Simple? Evolvale? Extensible?) Commercially successful, delivering value to their businesses and reducing costs. > > > > >> > >>> > >>> But in EVERY project I've ever had the major issue has not been the > >>> technology but the communication between teams and organisations on > >>> the application and business level interactions that we have been > >>> delivering. > >> > >> So then...if decentralization (e.g. aiming at less team-2-team > >> coordination) is your issue REST is the only style that actually has > >> to offer something.[1] > > > > Errr, eh? REST doesn't offer anything at the application and business > > level, I'm still waiting for the application (or even resource) > > interface definition and URI standardisation, let alone the rest of > > the puzzle (security, reliability etc) > > Hmm...where is the link to decentralization? You have to communicate the elements I said to all people, other approaches provide better communication mechanisms than those proposed for REST so far. > > > > > I've done multi-team interactions successfully, and everytime the key > > is to get those interface specs agreed. Whether its publishing a CSV > > format or a full WS-* spec then it needs to be done, right now REST is > > on the CSV format side of the fence. > > REST lets you start deploying *before* everyone agrees on everyting. > That > is the whole point I am afraid (Independent Evolvability of Components). Ah so REST invented iterative delivery as well? I thought that was "Agile" (or was it Spiral?). You should _not_ have to write code in order to agree an interface. > > > > > > >> > >>> The percentage of time spent on this part has dwarfed the time > >>> spent developing the bit of code that shifts information from A > >>> to B. > >> > >> Exactly! That is why a style that inherently adresses the issue of > >> decentralization has IMHO massive benefits even in the enterprise > >> context (although it has origially been designed for the Web). Less > >> need for coordination cuts down time spend in meetings, frustration > >> and cost...and it yields faster deployment circles. > > > > Why is there less need for co-ordination in REST? I'm really, really > > missing something here. How do you publish to say 120+ different > > developers the interface specification they have to obey in order to > > publish 4 different sets of information into the enterprise? > > (Oversimplyfied) you set up the server and let the clients figure it > out. Can't wait to tell that to the CIO or the business.... I remember criticizing a very rubbish GUI design once and being told by the person in question that "the users would figure it out", it was a complex business scenario and to figure it out would take on average 5 billion years thanks to the stupid way "Roy" had desgined it. > > The cool thing is that communication works because the interface is > uniform. Whoever wants to use your service finds everything she > needs in that first GET. Ah right, so GET contains a full detail of the total potential interaction with the service, thus solving both the Busy Beaver and Halting problems in one simple call? > > Ok, she then needs to implement it and maybe she needs to extend the > formats, but if you produced something extensible, the system can > gracefully evolve. Easy to write on paper, not so easy to do in practice. > > > > > How do you publish the interface spec between 10 suppliers and a > > company to agree on how to do vendor managed inventory? > > With a Web server..... > > You think that is naive in an enterprise context? I think it is just > about > the paradigm shift that is needed to reduce the enterprise software > complexity. I think its worse than naive. > > Likely, people will find that deriving a new style from REST (by adding > constraints) works better for the enterprise context ; thst is just > natural > evolution. Or more likely people will continue doing something that ACTUALLY WORKS, rather than getting rid of all decent engineering principles. Amazon document their APIs pretty completely. That is a good thing, it reduces the amount of support calls and questions on the forums and gets people working quickly. Why can't you accept that the Amazon route is the way to go? Why do you think that Amazon have got it so wrong? > > > > > I know how to do this with WS-* and it really does cut down the > > fustration and effort over CSV and FTP shifting, but I'm still not > > seeing the REST solution that is easier. > > There are missing pieces (e.g. appropriate mime types such as > something UBL-like) to make people forget about HTML and > human2human interaction - once we have that, it should become > clearer. I agree it is hard to see - and likely unsellable to Joe > Developer's > boss right now. But we are working on it :-) And right now with the information I've received I've moved from thinking REST v WS-* was pointless, to thinking that REST is an alternative religion in the way XP became an alternative religion. That isn't a good thing. > > > > > > >> > >>> What I'd like to see is people concentrate on solving that problem > >>> rather than yet another "magic" improvement to shifting data > >>> around. REST has clearly not advanced the state of the art for > >>> this problem, and has indeed regressed against previous approaches. > >> > >> Fair claim - any proof? > > > > This thread? Seriously there have been many issues with Jini, RMI, > > RMI-IIOP, DCOM, CORBA and WS-* but at least they had a concept of a > > formal interface. Right now we can't on this list agree on a > > standardised naming convention for the URI, or on the standard way of > > publishing the interface to consumers... including doing that BEFORE > > the service/resource has been built. > > Right - we simply don't want to do that. So what you are saying is that people should get an extensive background in distributed systems then ignore that understanding? Why does Amazon do what I want then? > > > > > That is to me a step backwards, and I've been looking around alot and > > I'm not the only person who sees that as an issue and there are > > several attempts at solving this problem for REST, some have been > > mentioned on this thread in fact. > > > > Shifting data from A to B is TRIVIAL and has been for 20 years, its > > been commoditised for 15 years or so. The challenge is a layer above > > HTTP operates at the layer above. It is not shifting data, it > transfers resource > state (object state). No it doesn't, the state remains on the server the document returns the current representation of the state, because the server can change the state independently of the client. This is what you have previously said about state and clients. > > > that and right now WS-* with its obsession with technical specs like > > WS-TX and REST with its lack of any formalism > > there is no lack of formalism - maybe you refer to the lack of mime > types > for the usual business scenarios? Nope, the belief that MIME types will solve this is in the naive category. > > > are not making my life > > much easier in delivering multi-partner commercial systems. > > I hope I can keep you trying until it can be made clearer... Explaining why you think Amazon isn't doing REST because they insist on documenting their interfaces would be a good start. > > Jan > > > > > > >> > >> Jan > >> > >> [1] Set aside ARREST and friends: http://www.ics.uci.edu/~rohit/ > >> ARRESTED-ICSE.pdf > >> (A must read for anyone involved in dezentraslised system > >> design) > >> > >>> > >>> > >>> > >>> > >>> On 09/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > >>> I started to write a response to Gervas & Sanjiva's emails, but > >>> then it > >>> got long enough and tangential enough to what we were discussing > >>> that I > >>> decided to post it instead. > >>> > >>> Basically it tries to illustrate why Steve and other people > >>> (including > >>> myself, depending on the day) may be having so hard a time > >>> understanding > >>> REST. It also echos what Jan said about the relationship of WS-* to > >>> CORBA, but not quite so succinctly... ;) > >>> > >>> You can find it here if you want to read it: > >>> http://atownley.org/2006/12/socio-political-and-commercial- > >>> motivations-for-ws/ > >>> > >>> Cheers, > >>> > >>> ast > >>> -- > >>> Andrew S. Townley <[EMAIL PROTECTED]> > >>> http://atownley.org > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > Yahoo! Groups Links > > > > > > [EMAIL PROTECTED] > > > >
