CentraSite Documentation : Runtime Governance with CentraSite : Important Considerations when Configuring REST or XML Virtual Services : Endpoint Manipulation of REST or XML Virtual Services
Endpoint Manipulation of REST or XML Virtual Services
 
Example 1
Example 2
Example 3
Example 4
Example 5
Example 6
When you configure a virtual REST or XML service, you specify the native service name, an endpoint, and the HTTP method type(s) that are included in the message (POST, GET, PUT, DELETE). From this information, CentraSite will generate a virtual service definition that includes service and operation elements, as well as an endpoint and binding element pair for each HTTP method specified.
CentraSite will automatically generate an operation name to be included when the virtual service definition deployment message is sent to Mediator. This means that if you create a virtual service called VS1, and you specify a native endpoint, then the endpoint exposed by Mediator for calling the virtual service will be /ws/VS1/Invoke.
For example, assume the following endpoints are deployed.
Native service endpoint:
http://localhost:8080/services/mtc/member
Virtual service endpoint:
http://localhost:5555/ws/VS1/Invoke
Assume that the example virtual service is deployed with two HTTP method bindings: GET and POST. Both of these bindings have operation elements that include the same HTTP location attribute: member. To better illustrate the functionality, the examples below show a series of sample requests from a consumer including the requests' HTTP method and Content-Type. (At run time, REST message detection is dependent upon a consumer using the correct Content-Type when a request is sent.) Each example shows the expected endpoint that Mediator will send after it has rewritten the endpoint prior to native service invocation.
Copyright © Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback