[
Lists Home |
Date Index |
Thread Index
]
> 1) The redundancy of submitting either of these message to a single
> end point (identified by URL) and the additional 'path' argument to
> specify which resource to apply the method.
Where does SOAP say you're limited to using just one URL? I know
it's more common to have a single URL for the whole service, but since
you're presumably writing the server (assuming since you mention PUT
below), there's nothing preventing you.
> 2) This is the real show stopper for me. Basically, having to submit
> XML content within a SOAP message is problematic ...
Yup; it's a generic XML-in-XML problem. You might want to think about
multipart MIME, which both SOAP and REST engines should be able to
handle. Yes, it requires both sides to do some work. Using GZIP on
the HTTP layer might be a bit more transparent and get similar effect.
> or encode the document in a portable binary format (base64 is what I
> decided upon in my case)
Yes, that's what everyone does.
> 1) It seems xPath,fetchResource are distinct enough to require a
> seperate service for each
My first inclination would be to encode the XPath expression as a
query parameter, sop that
/foo/bar does fetchResource
/foo/bar?xpath='.....' does xpath
As long as /foo/bar doesn't change, the xpath representation wouldn't
change, so it meets the GET criteria...
> 2) Are the semantics of PUT/POST distinct enough to justify using POST
> for the xUpdate submission and PUT for the setContent submission?
That's my reading of it.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
|
