Jan Algermissen wrote:
> 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.
Humm, but it has been said here that HTTP is an application layer protocol.
The
semantics of INVOKE are well defined. A remote reference is indicated in the
payload which is the service as a URI is in HTTP. The parameters of the
method
call are arbitrary, but particular to the service, just like the payload of
POST
or PUT. The INVOKE always returns a reply as HTTP does. Help me understand
what is not uniform about that?
>>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).
So if I define the interface
public interface Rest {
public InputStream get( URL u, List<String>hdrs );
public InputStream post( URL u, InputStream content, List<String>hdrs );
public InputStream put( URL u, InputStream content, List<String>hdrs );
...
}
I could create a RESTful service definition over RMI using Java?
>>>>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.
I am trying ask where does RESTs single mode of operation really add value vs
using say, the RMI model, where you can have RESTful or very specific APIs that
allow the programmer and user to understand the scope of the service they are
accessing.
In a focused API defined by a programatic interface, such as a Java interface,
the user can tell much more about the effects and parameters of the service
then
if you just give them a URL. They have to know to use PUT vs POST. They have
to know that GET has restrictions on use compared to POST. They have to know
the semantics of the transfer protocol, in addition to the services
parameterization. HTTP works, and RESTful architectures do function, but from
my view neither really adds any value to making your SOA better.
Gregg Wonderly
------------------------ Yahoo! Groups Sponsor --------------------~-->
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/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/
