In previous post, we are introduced to native REST services (Typed and Un-typed) support in 12.2.1. But we can observe following issues there:
- We used only GET method for demonstration and typically this would not be the case as REST service can also support other HTTP methods (POST, PUT and DELETE).
- No branching in Typed REST Services when multiple HTTP methods are supported.
- No branching in Un-Typed REST Services when multiple HTTP methods are supported.
In this post, we will try to cover above aspects. Note that all of this discussion is related to native REST services unless stated otherwise.
Branching in Typed REST Services:
Add POST method support for typedEmployees resource as shown below.
Since Typed REST Service uses WADL and contains Operation name annotated with soa:name, we can simply make use of Operational Branch.
You can use URL like below to access REST Service.
http://localhost:7003/restDemo/typedService/typedEmployees
Branching in Un-Typed REST Services:
Since Un-Typed REST services does not use WADL, we can’t use Operational Branch as above. So in this release, OSB introduced a new node called REST Branch for this purpose.
Add REST Branch in pipeline by dragging it from Components.
For each REST branch, give supported Media Types, Resource Path and HTTP method mandatorily.
Use + icon to add media types and give other information as shown below. This means we are creating a REST resource called untypedEmployees which supports GET and supported media types are application/xml, application/ json.
Modify REST branch name in General section of Properties. We can add more branches using highlighted icon below.
We can add POST method support for same resource path as shown below.
Test Proxy as shown below. Note that we had specified required parameters in HTTP headers.
You can use URL like below to access this REST Service and make sure that Content-Type is passed without fail.
http://localhost:7003/restDemo/untypedService/untypedEmployees
Observations:
- OSB parses payload based on HTTP header Content-Type in request. We can Use Log activity to see $body contents. Refer to this post to enable logging.
- When Content-Type is application/xml, $body is logged as below.
PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: <soapenv:Body xmlns:soapenv="http://schemas. xmlsoap.org/soap/envelope/">[[<a><b>1233333</b></a></soapenv:Body>]]
- When Content-Type is application/json, $body is logged as below.
[PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/ soap/envelope/">{"a":1234,"b":3455}</soapenv:Body>
- OSB binds a globally-scoped object called process and can be used as process.body or process.var which is similar to $body and $xyz XPath variables. This notation is used for Java Script expressions. Use Log activity as below in Java Script expressions to verify the same.
- When Content-Type is application/xml, process.body is logged as below
[PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: <a>[[<b>1233333</b></a>]]
- When Content-Type is application/json, process.body is logged as below
[PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: {"a":1234,"b":3455}
- Though REST service supports JSON/XML payload, there is no automatic conversion takes place at runtime and to be done programmatically in native REST services.
- When using End-to-End XML, use XQuery/XSLT for transformation.
- When using End-to-End JSON, use Java script for transformation.
References:
Siva's Blog 