FnP for HTTP binding and SOAP HTTP binding

abstract level:

 The goal of defining them at the abstract level as well would be to
 provide a _hint_ to the implementation. Their use is not
 required. Mapping XML Schema complexType into an HTTP GET won't be
 done. Of course, you can serialize the Infoset in the URI but who would
 like to use those uris? Based on the abstract feature, one can
 determine if a result is cachable for example, even if an HTTP POST is
 used underneath.

 feature
  name http://www.example.org/CRUD
  
 property
  name: http://www.example.org/method
  value space: create | retrieve | update | delete



binding level:

HTTP binding:
 feature
   http://www.example.org/2003/03/http/web-method
   property
    name: http://www.example.org/2003/03/http/web-method/method
    value space: PUT | GET | POST | DELETE

SOAP HTTP binding:
 feature 
  http://www.w3.org/2002/12/soap/features/web-method/
   property 
    name: http://www.w3.org/2002/12/soap/features/web-method/Method
    value space: PUT | GET | POST | DELETE

issue: Do we need to invent a new uri for for the HTTP binding feature?

Well, not really, but it would be good if people don't associate
systematically the SOAP Web Method Feature with SOAP itself. They may do
since the uri provided in the SOAP specification contains "soap". It's
more a feature that needs to be attached to HTTP itself but the URI used
does not reflect that enough imho.

issue: and what about the HTTP headers?

How useful would it be? The accept, accept-ranges, content-type,
authorization, cache-control, connection and content-length are already
fixed by other means (security, authorization features). accept-language
has nothing to do in the WSDL. Do we have an example of an header that
needs to be fixed and should not be represented in a more abstract way?

Philippe

Received on Thursday, 10 April 2003 08:42:01 UTC