On Dec 7, 2006, at 7:10 PM, Steve Jones wrote: > > How do I document and formalise to a consumer how they get an invoice > or place and order? Start a standards process (could be intra-organsational or between trading partners etc. Better would be global scale (e.g. IETF), but start small.
There is also ebXML and UBL which propably already do what you need when combined with Web arch. I will in the near future take a deeper look, just had to many things to do. You can also transfer EDIFACT as MIME: http://www.rfc-editor.org/rfc/rfc1767.txt (though I lack any knowledge about EDIFACT). > What format do I use to describe the URI, > Request, Response, pre-conditions, post-conditions and invariants of > the invocation? How is this description then versioned, published and > managed. Either through a standards process or yo need to set up your own (in your context). > > Saying REST is simple means that this should be simple.... No, REST defines consraints that indice simplicity into the architecture...but it does so (for example) at the cost of having to standardize shared semantics. Granted, throwing together your proprietary interface wis WS-* is fas less effort, but it leads nowhere in terms of making your system any easier to maintain or evolve than Joe Developer's homegrown OO application. (Besides, serious WS-* does also aim at standardized APIs (e,g, for an ordering process). Jan > > > > > Jan > > > > > > > > > > > > >> > > >> > > When you browse a URL, what does it mean? When you use a > SOAP service, > > >> > > what does it mean? When communicating on this mailing- > list, what does > > >> > > it mean? I think you're stretching the term "meaning" > here ... :) > > >> > > > >> > No I'm not. When I use a SOAP service I have the name of the > SOAP > > >> > endpoint and the port as well as the schemas that define the > > >> > documents. There is the concept of this being published > upfront in a > > >> > standard way, with Service names and ports having sensible and > > >> > descriptive names. > > >> > > >> All you have through this is your connection points, schemas, > API's > > >> and so forth. This is *not* meaning. Meaning is what you make > of it. > > >> Full automata of services is a pipe-dream, no more realised > with WS-* > > >> than anything else. In the end, there's developers like you > and me > > >> deciding what to connect to where and how to use it. > > > > > > > > >Meaning is exactly what I make of it, and when I have all the WS-* > > >information available them I'm able to make a hell of a lot of > meaning > > >(correctly) out of the provided artefacts. If using REST I'd > need to > > >do the same, but REST doesn't appear to have a standard way of > > >publishing this information to consumers. > > > > > > > > >> > > >> > > The *meaning* of a URL is whatever we make it. There's > guidelines > > >> > > which says we should make URL's as meaningful as possible, > but there's > > >> > > no requirement to do so. But if we can, we should, just > with any other > > >> > > URL out there; REST builds on some nice human principles of > > >> > > exploration that I find very attractive. > > >> > > > >> > Hang on you said it was Opaque and now saying it should be > > >> > meaningful.... which is it? > > >> > > >> *I* certainly didn't say "opaque" ... I'm much too simple to > use such words. > > > > > >Sorry it was Jan who said that. I get confused easily with all the > > >contradictions coming in this thread! > > > > > >> > > >> > > Sounds like you're trolling... > > >> > > > >> > Not at all, having an approach which is "call it and see" > isn't really > > >> > viable commercially. > > >> > > >> Why not, exactly? > > > > > >1) It might not have been built yet > > >2) I need to publish the information to the consumers > > >3) That information acts as a formal contract between the two areas > > >4) Call it and see cannot be viable for full traversal (I can't > > >guarentee full coverage as I don't know what I'm looking at) > > >5) Communicating change via "it is now broken call it again to work > > >out how it works now" isn't viable. > > > > > >I could go on, but having an integration project (which is what > REST > > >and WS-* are) without formal interfaces is (IME) project suicide. > > > > > >> > > >> Alex > > >> -- > > >> "Ultimately, all things are known because you want to believe > you know." > > >> - Frank Herbert > > >> __ http://shelter.nu/ > __________________________________________________ > > >> > > > > > > > > > > >
