David, On Mon, Sep 19, 2005 at 08:17:06AM -0600, David Forslund wrote: > If the interface is the same how do I know if one is asking getAge or > getInvoice?
You (as a client) know because you might have previously received a document which included some information which told you what it was, or described it in some way which made you want to dereference it (a search spider is the degenerate form of this type of client - it dereferences all URIs independent of the context for that URI). For example, within whatever ML you might be using, you might see something like this; <Invoice href="http://example.org/lkasjfdlkadjfsdf"/> ... which says, in the semantics of the ML in which its expressed, "That's an invoice". GET on it then has obvious meaning. >What about other operations besides > get and set? For the most part, POST fills those needs, where the client simply submits a document (no operation included) to a URI. For example, ordering something can be achieved by POSTing an order document to a order processor identified by some URI. As above, you might learn that via some XML like; <OrderProcessor href="http://example.org/wieruojasdfias"/> There *are* some operations which don't fit into this model very well, and some of those may be general enough to motivate new HTTP operations (e.g. WebDAV's COPY and MOVE). But in my (extensive) experience with Web based integration, I've only ever had to stray from GET/PUT/POST/DELETE, or use operation tunneling over POST, on three occasions (out of 100s, possibly 1000s, of deployed interfaces). >What about "Find all individuals with a last name that > sounds like this name?" This type of question > needs to be encoded in the payload. If you send this message to my > server that only knows "age" (based on some > earlier context or "state"?), it can't intelligently respond to the > question. One needs to have a way to "register" the > server's capabilities as to what it can respond intelligently to. Exactly right. That's the role played by form languages. Note that, in your example, the only pure operation is "find"; everything else is just a description of an abstraction ("individuals with a last name that sounds like $foo"). That means you could map the request to a URI using a query form - perhaps something like this; <SoundsLikeNameQuery href="http://example.org/iuuiuiuiuiu";> <Param name="name" type="http://example.org/type/lastName";> </SoundsLikeNameQuery> A client using that form could construct a URI; http://example.org/iuuiuiuiuiu?name="forslund"; .. and GET on that would give you your answer. With more complex queries that don't serialize into URIs nicely, you may need to use POST though. That's not RESTful IMO (Roy Fielding disagrees with me), but you don't need the operation "find", you just need, as above, to post the data - the last name - to the right resource ala; <SoundsLikeNameProcessor href="http://example.org/jierewre"/> To fully answer your excellent question would take a while though, as we'd have to dig into REST's "hypermedia as engine of application state" constraint, and explain its value relative to the alternatives (such as a separate query application protocol or HTTP extension). And that's not to suggest that alternative approaches aren't useful in some cases, but just to say that a purely RESTful approach does exist. > Certainly a registered API is one way to do this. Other > ways must be substantially equivalent to this and save nothing in terms > of implementation or deployment, since code > equivalent to the API must be embedded in the server. Respectfully, I don't think that's a very useful way to look at the difference. If you looked at it in architectural terms, you'd be able to evaluate the architectural properties lost and gained from the adoption or rejection of known constraints, and evaluate the resulting properties for suitability of deployment in the target environment (e.g. the Internet). An typical Web services approach, for example, rejects API constraints, and therefore sacrifices - compared to an equivalent Web based approach - significant simplicity, scalability, and reliability. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
