I don't think you are dumb. An example would go a long way here.
How about an example (even a simple example) of how to do workflow
with REST? Then we can see how one answers this question in a "real"
problem.
Dave
Dan Creswell wrote:
>
> Jan Algermissen wrote:
> > On Jul 11, 2006, at 5:54 PM, Dan Creswell wrote:
> >
> >> And as it appears that's what you'd have to do many people are
> >> wondering
> >> how that's much better than defining it all on some contract/interface
> >> be it implemented via RPC or some other mechanism.
> >
> > Because there will be integration at some point and with e.g. RPC you
> > have to deal with:
> >
> > - the behavioural contract
> > - the API
> > - the data
> >
> > with REST you only need to consider
> >
> > - the data
> >
> > IMHO it is much easier to *only* having to translate between
> > different data representations of state than it is to translate
> > between different behavioural and API contracts *and* the data.
> >
>
> How do you know what to translate and to what?
>
> And how do you know what's going to be done with what you translate -
> i.e. what behaviour is behind that get or put or whatever?
>
> Think I'm just dumb........
>
> > Jan
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
> _
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/
