Rob Eamon wrote: > --- In [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com>, Gregg > Wonderly <[EMAIL PROTECTED]> wrote: > > > > Rob Eamon wrote: > > > From an SO perspective, when will the URI of a service operation > > > be directly exposed to a user of a UI? Won't URIs predominantly > > > be used at design-time and/or as a configuration item for the UI > > > app, at least at the entry level of the service (UI calls an > > > operation using configured URI to start, then calls other > > > operations using URIs returned by that and subsequent > > > operations)? UIs aren't part of the service, correct? > > > > What this assumes is that you will always get the work flow right > > the first time and that there are not any desirable variations on > > how the work flow might be better facilitated for certain > > circumstances. > > Are you assuming that the service defines the workflow? IMO, it does > not.
A service confines the workflow to the operations it supports. Hypermedia, returned by restful services provide a strong indication of work flow they desire to be used. The Back button on a web browser is one way that this workflow is circumvented. Another is litteral typing of URIs. > > For me, a service is something that exposes resource that are of > > interest to a work flow. > > Resource, operation, etc. Yes. The operations are fixed for restful services. If we are talking about other types of services, then the operations might still be 'fixed', but be more specifically enumerated and controlled. > > That work flow is something that a client implements. With HTML > > web pages, we provide some choices of possible work flows through > > hyper links. Have you ever pushed the "Back" button on your web > > browser? That indicates that the "service" did NOT provide you > > with the right work flow. > > If the workflow is something the client defines/implements, doesn't > it indicate that the client implementation did not provide the right > workflow? Thus it is a change to the client, not the service, that is > needed via design-time or configuration changes. I am talking specifically here about restful services and hypermedia returned as the result of interacting with such a restful service. That hypermedia is supposed to "direct" the workflow by providing the appropriate next "actions" to take by using the contained hypermedia. Thus, the client is confined in the choices it can "automatically" support, except for the two mentioned above, back, or an explicitly typed URI that goes to a completely different service. > IMO, a client application is not a service, nor is it part of one (my > opinion directly influenced by Krafzig, Banke and Slama). I don't think I am saying that a client is a service. I'm saying that a client using a restful service is confined by the hypermedia that it receives from that service. This limits the choices of workflow and is why I think that saying URIs should be non-interpretable by humans is not a useful argument. Workflows that are the most productive is what we try to achieve. Practically though, we still can make arbitrary decisions about what the next "task" to perform might be. Saying that a restful service's returned hypermedia is the only way to complete and order a work flow, for me, is a bit of a stretch. Sure there are some things that need to happen in order. But, there are always some things that don't need to happen "here". Allowing users the ability to make those decisions and to enter URIs to access a particular resource explicitly improves their productivity in many cases. Gregg Wonderly Gregg Wonderly
