I would find it very difficult to talk to people if I could only use nouns. Restricting communications to nouns seems incredibly restrictive. I know the Web has been very successful with a restricted set of "verbs", but the web isn't very natural for doing distributed workflow, clinical decision support, etc. I would like to see a simple REST "interface" for Workflow with the same functionality that is in the existing Internet standards for this service, for example. Something that I could send someone (or they could get from a standards body) and know exactly what the system behavior on the other end is. Behavior doesn't involve nouns. It involves verbs and can involve state. If I can't have a machine readable specification of the system behavior of some kind, I don't think interoperability is really achievable.
Jan Algermissen wrote: > > On Sep 19, 2005, at 4:22 PM, David Forslund wrote: > > > But MIME types/namespaces don't easily express verbs, do they? > > Stop thinking about verbs, think nouns. There are no getStockQuote > methods in a REST system. It takes time, but once you got your mental > model rewiring, the future is bright :o) > > > Obviously I can do "anything" through the http interface, but this > > doesn't make > > it easy or natural. > > It is not about doing something 'through' the HTTP interface, it is > about the HTTP interface being the common interface for the objects > that make up your application. I guess this is a point of view, but IMHO, http does not handle "objects" at all. > > Regarding REST feeling 'natural' to OO heads...try thinking in > patterns. After all, patterns are much like architectural > constraints. The 'Active Domain Object' data access pattern (fetching > complete objects state from database once instead of contacting the > DB for each of those getName() methods) for example takes you at > least half the way from traditional EA OO thinking towards REST. > Maybe it helps to think of the uniform interface in terms of the > Facade pattern (hiding complexity for the sake of evolvability). This is helpful, but the Facade pattern simply hides the complexity (in a useful way). Someone still has to do the work. And the work is the same in any case. The transport mechanism is incidental. I've done distributed apps for many years with almost no concern over how data is moving between client and server. I would not like to have to give that up to use REST. The WS approach is actually much more complex and less interoperable that what we have been doing, so I really don't like going that way. Dave > > Jan > > ________________________________________________________________________ > _______________ > Jan Algermissen, Consultant & Programmer > http://jalgermissen.com > Tugboat Consulting, 'Applying Web technology to enterprise IT' > http://www.tugboat.de > > > ------------------------ 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/
