the W3C just launched a
resource access, but last time i checked, the web was all about resource access, and HTTP was the protocol doing a pretty good job at it.
it really seems to me that the SOAP community is still busy rebuilding the complete internet and web protocol stack on top of the HTTP transport layer, and now they are rebuilding HTTP. i am sure this is not entirely true, but i am worried that it is not completely false, either. this is the beginning of the introduction from one of the deliverables of the new working group, WS-Transfer:
This specification defines a mechanism for acquiring XML-based representations of entities using the Web service infrastructure. It defines two types of entities: Resources, which are entities addressable by an endpoint reference that provide an XML representation, and Resource factories, which are Web services that can create a new resource from an XML representation. Specifically, it defines two operations for sending and receiving the representation of a given resource and two operations for creating and deleting a resource and its corresponding representation.
This specification is intended to form an essential core component of a unified resource access protocol for the Web services space. The operations described in this specification constitute an extension to the WS-Transfer specification, which defines standard messages for controlling resources using the familiar paradigms ofget,put,create, anddelete. The extensions deal primarily with fragment-based access to resources to satisfy the common requirements of WS-ResourceFramework and WS-Management. This document constitutes WS-ResourceTransfer, hereafter referred to as WS-RT.
if that does not sound a whole lot like HTTP with the idea of fragment identifiers as established through URIs and media types, i don't know. like i said above, i am probably missing some of the finer points about this activity and the proposed specifications, but looking at the general tendency of SOAP to just use HTTP as a transport protocol, i also would not be surprised to see that to a large extent, this new activity is essentially building HTTP over SOAP over HTTP.
unfortunately, the specifications quoted above still use and claim ownership over the terms
web services infrastructure and
web services space, as if SOAP was the only way to do
web services. it is not, and RESTful web services are becoming more and more important. but it is a pity that the
web services term is still held captive by such a narrow concept of what a
web service is. i am always struggling what to say when i am talking about the wider idea of
web services, and often i am falling back to the term
web-based services, but this mostly confuses people and many still think i am talking about SOAP. maybe we should start talking about
SOAPfree web services or something along these lines...
i would love to be proven wrong here, so if i am missing something essential that would make it impossible to just use HTTP for the resource access specifications targeted in that new working group, i would be interested to learn about it.