> > Another example is web browsers.
> > To date, I've yet to see one that supports "tcp:<portno>".
>
> OK, we've opened up sockets. Now what do we do? What do I expect from
> you, or you from me?
The URL structure can spell that out just like it does for HTTP and FTP. I.e.
what difference is there between following in either the transfer or the
transport case?
http://myhost/path/to/file.type
ftp://myhost/path/to/file.type
tcp://host:port/path/to/file.type-or-mime.type
http uses mime-types to tell the user/browser what it is receiving.
ftp requires tha the user know about the type, or that there be a filename
extension to indicate the file type.
A tcp implementation could specify a mime-type in the path, or a filename. This
would imply that the person using such a URL would have to know about the
service. That is my point. In the case where I have a context that contains a
set of URLs, why can't I just connect to a TCP port and get some data, be it
HTML, imagery, data or whatever? Most people would say this is too free form,
not controlled enough.
I'm just asking, if simplicity and flexibility is what everyone wants through
REST interfaces, then why do all references to resources need to use HTTP and go
through a web server's servlet container, etc. Wouldn't it be easier to talk to
them directly when there was well defined, expected behavior?
Gregg Wonderly
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
