|
Page Edited :
ODExSITE :
WSDL 1.1 Extensions for REST
WSDL 1.1 Extensions for REST has been edited by Alexis Midon (Jul 16, 2008). Content:WSDL 1.1 Extensions for better HTTP/REST descriptionThe Resource-Oriented Architecture defines four concepts:
and four properties:
HTTP binding as defined in WSDL 1.1 is not well suitable to implement these concepts and properties, mainly because a port type may access 4 different locations/resources but with only one HTTP method. To better describe RESTful services, and turn a port type into a "resource type", ODE brings a set of 4 extensions:
Further details below. In this page, we use an imaginary blog service as a use case to illustrate and make things more palpable. We will focus on the resources defined by the following URI template: http://blog.org/post/\{id}
One verb per operationAccording to the WSDL 1.1 specification, the verb describing the HTTP method has to be at the binding level So, this extension is to push down the HTTP verb at the operation level. And if an operation does not have its own verb, then the verb defined at the binding level will be used. Please note that ODE supports GET, POST, PUT, DELETE only. <definitions ...
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
<!-- many wsdl elements are ommited to highlight the interesting part -->
<binding name="blogBinding" type="blogPortType">
<operation name="GET">
<odex:binding verb="GET" />
</operation>
<operation name="DELETE">
<odex:binding verb="DELETE"/>
</operation>
</binding>
</definitions>
URI TemplateA RESTful service exposed a set of resources, each of them being accessible through a uniform interface: the HTTP methods. So we need a way to define four operations (at most) for a single resource. Moreover it's very likely that the resource URI actually describes a set of resources. For instance, the set of posts contained in our imaginary blog: http://blog.org/post/\{post_id}. HTTP binding offers the http:operation <definitions ...
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
<service name="blogService">
<port name="blogPort" binding="blogPortType">
<http:address location="http://blog.org"/>
</port>
</service>
<binding name="blogBinding" type="blogPortType">
<operation name="PUT">
<odex:binding verb="PUT" />
<http:operation location="post/(post_id)"/>
<input>
<http:urlReplacement/>
</input>
<output/>
</operation>
</binding>
</definitions>
However, here 3 issues show up:
To solve this, ODE allows http:operation In addition, the http:urlReplacement is relaxed: all parts are not required in the URI template anymore. One part could go in the URI, another in the request body. <definitions ...
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
<service name="blogService">
<port name="blogPort" binding="blogPortType">
<!-- here is the full URI template, using curly brackets -->
<http:address location="http://blog.org/post/{post_id}"/>
</port>
</service>
<binding name="blogBinding" type="blogPortType">
<operation name="PUT">
<odex:binding verb="PUT" />
<!-- location attribute intentionally blank -->
<http:operation location=""/>
<input>
<http:urlReplacement/>
<!-- an additional part can be mapped to the request body even if urlReplacement is used-->
<mime:content type="text/xml" part="post_content"/>
</input>
<output/>
</operation>
</binding>
</definitions>
HTTP Headers manipulationHHTP protocal convey a lot of information in Request/Response Headers. Caching information, Content description for instance. All this data is completely left out by WSDL 1.1 HTTP Binding. To fix this, ODE provides a header element. This element can be used to insert a part or a static value from a message to a given HTTP request header (standard or custom). And the way around, a HTTP request header into a part. Also note that all HTTP response headers are inserted into the message headers, and thus are available from the BPEL process. <definitions ...
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
<binding name="blogBinding" type="blogPortType">
<operation name="PUT">
<odex:binding verb="PUT" />
<http:operation location=""/>
<input>
<http:urlReplacement/>
<mime:content type="text/xml" part="post_content"/>
<!-- set a standard request header from a part -->
<odex:header name="Authorization" part="credentials_part"/>
<!-- set a custom request header with a static value -->
<odex:header name="MyCustomHeader" value="[EMAIL PROTECTED]" />
</input>
<output>
<mime:content type="text/xml" part="post_content"/>
<!-- set 1 response header to a part -->
<odex:header name="Age" part="age_part"/>
</output>
</operation>
</binding>
</definitions>
In addition to HTTP response headers, for every HTTP response, the Status-Line <Status-Line> <HTTP-Version>HTTP/1.1</HTTP-Version> <Status-Code>200</Status-Code> <Reason-Phrase>OK</Reason-Phrase> <original>HTTP/1.1 200 OK</original> </Status-Line> So that you can write the following BPEL lines: <assign> <copy> <from variable="postMsg" header="Status-Line"/> <to>$statusLine</to> </copy> </assign> <if> <condition>number($statusLine/Status-Code) > 200 and number($statusLine/Status-Code) < 300</condition> <empty/> <else> <assign> <copy> <from>'Request successful!!!'</from> <to>$outputVar.TestPart</to> </copy> </assign> </else> </if> Fault SupportAnother domain completely neglected by WSDL 1.1 HTTP Binding is Fault management. The world is not even mentioned in the HTTP Binding section |
Unsubscribe or edit your notifications preferences
