On Jun 27, 2006, at 5:44 PM, Gregg Wonderly wrote:
>
> The predominant theme of REST discussions here has been using HTTP
> because of
> the number of resources available today which are visible through
> HTTP servers.
> Java RMI has only one operation, INVOKE. Does that make it uniform
> and thus
> RESTful?
No, because we are talking about application layer protocols and
INVOKE has
no application semantics.
>
> > There is also no problem imposed by adding methods, as long as they
> > can usefully be
> > applied to *all* objects of the system. WATCH (aka MONITOR) would be
> > such a method and
> > there are also PATCH or MKCOL (from WebDAV).
>
> And this can be done with Java interfaces through subclassing
> without affecting
> existing users as long as codebases are used for defining the
> source of classes
> needed to resolve the clients proxy to the service.
Yes, but remember that the interface is only uniform if the methods
ake sense for all objects
(even if some do not implement them all). For example, MKCOL isn't
strictly uniform because it
makes assumptions about the nature of the resource (that it is a
collection).
>
> >>HTTP GET, PUT and POST have no meaning without a URI.
> >
> > Not true. See HTTP specs. The meaning of the operation does *NOT*
> > depend on what resource it is invoked on.
>
> Humm, I believe that without a URI there is only a single service.
> If you put
> everything in the payload, then yes, you can move the designation
> of the action
> into the payload instead. That is then identical to RMI, CORBA and
> other RPC
> transport protocols which have a single operation, INVOKE.
I don't understand how that relates to the discussion.
>
> >>It is that URI that is
> >>the denormalizing force for me.
> >
> > Can you explain what you mean by 'denormalizing' here?
>
> The fact that something different happens on the server based on
> the URI or an
> embedded action designation in the payload makes the GET/PUT/POST
> operation a
> simple side issue. It doesn't actually make a real difference in
> what the
> service WILL do. The implementation of the servlet/cgi/... can
> consider that
> operation differently, but any design service could always use
> POST, and just
> describe the differentiating action in the payload.
NO! Because that is using HTTP as transport and not as transfer.
Consider the
two ways to turn on a lightbulb
lightbulb.POST( "invoke('turnOn')") // using HTTP as transport
vs
lightbulb.PUT( "ON" ) // transferring the 'ON' state to the lightbulb
> GET/PUT/POST are nothing
> more than 'words' from that perspective. They don't directly
> describe, to the
> client, what exactly will happen any better than
> makeAChangeToThisData(...) does.
If you intend to use HTTP properly, you do not get to choose the
perspective, the
spec is what you have to look at. And that specs clearly defines what
the methods
mean and what a client can expect to happen.
Sorry to repeat, but.."HTTP is an application protocol"
>
> >>It is exactly that information that is the name
> >>of the service and operation that you wish to invoke some operation
> >>on. The
> >>data that you pass in that request is also varied.
> >
> > Hmmm...not sure what you are trying to say.
>
> I am saying that there is nothing dictated by the existance of all
> these bits of
> the HTTP protocol. They are all fully programmable behaviours. An
> application
> designer is free to use/abuse these features of the protocol in
> whatever way
> they want which has a denormalizing/non-unifying effect.
Sure you *can* do all that. You can also layer HTTP over WS-* if you
like.
But so what?
> Specifications which
> can't be enforced by API are not much of an asset to a programming
> system, for me.
>
What do you mean?
> >>It doesn't matter to me how you say
> >>service1, please add customer Joe Bob Bundy to the database.
> >
> > Well, I'd prefer
> >
> > srv.addCustomer( bobBundyObj ) over srv.AddCustomerBobBundy()
> >
> > and then I'd prefer
> >
> > customers = srv.findCollectionByMemberType( "Customer" )
> > customers.add( bobBundyObj )
> >
> > over
> >
> > srv.addCustomer( bobBundyObj )
> >
> > because it reduces the whole API complexity to a single ADD (aka
> > POST) operation (the find
> > operations is of course just a GET and subsequent, say, XPath
> > expression).
>
> There are subtle implications about program architecture which come
> out of
> service API design. At the very backend of the server, you will
> probably find
> that there are collections and simplified APIs that look like this.
> But,
> exposing these to the client, directly, tends to provide the client
> with more
> implementation details to depend on and thus creates less
> flexibility in service
> updates and changes in API to provide better/different service
> behaviors.
> >>In the end all bits and pieces have to travel from a client
> >>application to the
> >>environment where the work is done.
> >
> > But remember: before the bits travel, the peers have to engage in
> > communication. And this
> > is *a lot* simpler and potentially more fruitful when the API is
> > uniform[1]
>
> It is a lot easier when the client and server agree on enough well
> defined
> behaviors from both that the contracts implicit in those
> communications can be
> met. The more confined and directed an API is, the easier it is for
> the server
> to know what the client will depend on. The more confined and
> directed an API
> is the less implementation detail is visible to a client. This
> makes it
> possible for the service details to evolve such that the client
> doesn't have to
> worry about losing access to the service they depend on.
>
> Screen scraping HTML for data is a popular tactic on the internet,
> because we
> have pushed out HTML for formatting and often don't have parallel
> interfaces for
> just the data. So, people have written programs that open HTML
> URLs, and scrape
> through documents to extract information that is not otherwise
> available.
>
> It is the lack of a defined contract for such a service that I am
> speaking of.
> There is data visible to be consumed, which is not supposed to be
> consumed in
> the way it is consumed. There is too much information visible to
> the client
> that is not confined into a form that is independent from the
> container.
>
And you would say the same is true for, say Atom?
> >>How in the world does HTTP make it possible where anything else
> >>doesn't?
> >
> > Who says that only HTTP can stuff Bob into the customer collection?
> > HTTP is
> > just the opposite end to srv.AddCustomerBobBundy().
>
> Again, the RESTful discussions seem to revolve around how many HTTP
> accessible
> resources are available. So, I'm focused on why HTTP is of such
> interest in
> these discussions. Clearly, any protocol can be used to do this.
> So, why would
> you choose HTTP as the ONLY way to do this?
Not the only, but since HTTP is soo extremely well deployed, since
there are myriads of
libraries available, since there are programmers available that do
not need to be trained to
use all this and since we can expect that HTTP is a save technology
bet to put your money in
....that is why I'd prefer HTTP.
Jan
>
> > And regarding srv.AddCustomerBobBundy()...would you include
> *that* in
> > your
> > "It doesn't matter to me how you say..." :-)
>
> In a sense, this is what finally is resolved to happen no matter
> what the
> transport and invocation layer expose as divisions of the data space.
>
> srv(addCustomerBobBundy);
> srv.add(CustomerBobBundy);
> srv.addCustomer(BobBundy);
> srv.addCustomerBob(Bundy);
> srv.addCustomerBobBundy();
>
> All of these could to the work. URLs have the ability to trivially
> convey all
> of these variations with URL parsing performing data extraction in
> some way.
>
> But, in each case (in the order shown above) there are fewer
> constraints of the
> arguments that you have to understand, respect, and act on. It's
> this balance
> that the SOA architect has to find the right balance for.
>
> REST vs SOAP vs Jini/RMI vs CORBA is not the biggest issue here.
> That's my
> point. SOA is possible with many types of transport/transfer
> technologies used
> by these architectures/systems. The question for me is what
> language/SOA
> platform provides the most opportunity for system flexibilty,
> customization,
> versioning and ultimately security.
>
> REST, for me doesn't add value. It recreates existing capabilities.
> The
> implementation of these capabilities are not confined in the same
> way as the
> previous implementations were. This opening of the doors will lead
> to very
> interesting changes. Many think its great that so many
> implementation details
> are revealed, because you can use any part of the returned data.
> It's that
> level of dependency that locks the service down to what it can do/
> be. So, as
> soon as you need to rev the server, you have to understand every
> possible use of
> the data that you were returning before.
>
> I'm specifically worried about the HTML screen scrapers. I have no
> issues with
> well formed resources such as images, executables, XML and other
> well structured
> data. But, HTML documents, PDF documents, MSWORD documents and
> other content
> which has a standardized form, but which has content that is
> unstructured is the
> big issue for me on the web. Because HTTP can be abused in this
> way, I find
> fault in its use in a production environment. It enables transfer of
> information, but because the use of that data can not be
> constrained to the
> intended uses (the reason why the service was created to provide
> such data), I
> don't find any value in its use.
>
> Gregg Wonderly
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/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/
