Page History
...
Bridge 6.0.55.2 Runtime 2016.3 Builder 6.0.17.2With the E2E Builder, you can model REST services and develop software in the form of resources with RESTful interfaces. For more information on the concepts of REST refer to the Wikipedia pages of Representational State Transfer.
These pages explain, how REST concepts are implemented to the E2E Bridge. The implementation supports JSON and XML content types and provides an OpenAPI 2.0 Specification for a REST service documentation and test.
You could also use plain HTTP to build RESTful services yourself - how to do this is described on RESTful HTTP Service. However, this approach is recommended only for content types divergent to JSON and XML.
| Multiexcerpt include | ||||
|---|---|---|---|---|
|
Since Runtime 2018.5, the E2E xUML REST service supports IPv6.
For more information on how to access a REST service via the E2E Bridge, refer to REST Adapter.
...
Resources can be accessed via their resource path. Together with protocol, server name/IP, and port, the paths form URLs. Unless proxied, the protocol is always HTTP in the E2E Bridge.
The resource paths are calculated from the underlying model: the resulting path is a concatenation of all relative paths in the model hierarchy. The path starts with '/' - denoting server root - followed by the path definitions of the REST port type. Next, the path definition of each nested resource is appended, finalized by the path definition of the method.
Parts of the resource path can be dynamic, a so called path variable. This is a part of the path that can be given any value at runtime. Each dynamic path segment within a path has to have a unique name as it will be turned into an method parameter. Have a look at the figure above and the following examples:
| Resource | Class | Resource Path | Example Resource Path |
|---|---|---|---|
| support API | SupportAPI | /support | /support |
| support cases | supportcases | /support/supportcases | /support/supportcases |
| a specific support case | supportcase | /support/supportcases/:id | /support/supportcases/1234 |
| a specific method on a specific support case | supportcase | /support/supportcases/:id/resolve | /support/supportcases/1234/resolve |
| support cases of a customer | customer | /support/customer/:customerID | /support/supportcases/customer/0815 |
REST Parameters
Output
There can be exactly one output parameter that has to be of complex type. It will be written to response body. The format of the response depends on the definitions in the REST headers Accept and Content-Type. The E2E Bridge supports JSON and XML.
...
Input parameters can be provided via path, query, body, or header of the HTTP request.
| Parameter | Description |
|---|
| Example | |||
|---|---|---|---|
| path | Path parameters are part of the path and, in consequence, the URL. They are all required. |
| id on rest resource supportcase | |||
| query | Query parameters are appended to the path after the '?' delimiter in standard query-string. Query parameters are optional. |
| status and customerName on resource supportcases, method GET/ | |||
| header | Header parameters are transferred through request headers. |
| body | Body parameters are transferred within the request body. Since there is only one body, only one body-parameter can be defined for a method. The form of the body should correspond to the Content-Type header, or Accept header if the former is not present. Bridge REST services accept both, JSON and XML content types. |
| supportcase on resource supportcases, method POST |
REST Methods
REST Methods are methods that can be called on REST resources via HTTP requests. The E2E Bridge supports the following HTTP methods for REST methods: GET, POST, PUT, PATCH, DELETE, OPTIONS and HEAD. REST methods have their own path relative to the parent resource they are defined on. Refer to The REST Resource Path further above for an example and to Defining REST Operations for more details.
...
Analogously to the WSDL file of SOAP services, the E2E Builder generates an OpenAPI 2.0 Specification service descriptor encoded in YAML (Swagger), that describes the REST interface.
Since Bridge 6.0.55.1, the E2E Bridge comes with a REST service documentation and test tool that reads the service descriptor and shows an overview of the capabilities of the REST service. Furthermore, it enables you to interact with the service and perform HTTP calls. Refer to Testing REST Services for more details.
Overview
Content Tools