Versions Compared

Old Version 2

changes.mady.by.user Kirstin Seidel-Gebert

Saved on

compared with

New Version 3

changes.mady.by.user Kirstin Seidel-Gebert

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space WBRIDGE and version 7.7.1
Div
Classe2e-refDiv

Otp
Floatingfalse
maxHLevel2

Rp

The E2E Bridge helps you with implementing REST methods. This page explains how REST methods have to be implemented so they can be called via REST requests and how different kinds of REST parameters have to be defined so they are provided to the service automatically by the E2E Bridge.

Multiexcerpt include
MultiExcerptNamenative_rest
PageWithExcerptINTERNAL:_examples_BRIDGE

...

REST Methods

With REST methods, the E2E Bridge distinct between verb methods and named methods (as described in REST Service). REST methods have to be static and must have stereotype <<REST>>.

...

Verb methods intercept requests issued directly to the resource. Verb methods can only path parameters that are defined on the parent resource(s).
With the E2E Bridge, you can implement all available HTTP methods as REST methods, as there are GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS.

Noteinfo
iconfalse
titleThe Trailing "/"

Verb methods can be in form of GET or GET/. The difference is subtle but significant. It is important to understand the difference.

Have a look at the support manager example.

  • A GET with a trailing / on the URL should always return a list of resources. Issuing a GET on /support/supportcases/ is expected to return a list of existing support cases.
  • A GET without trainling / o the URL should always return more general information on the resources. A GET on /support/supportcases is expected to return information on the support cases in general, e.g number of support cases, list of customers afflicted, ...

...

Multiexcerpt
MultiExcerptNameError_Handling

Each REST port type should have a <<RESTError>> class assigned. The E2E Bridge will use this class as output in case of error (see Defining a REST Service Interface).

In the support manager example, REST port type SupportAPI has class RESTError assigned as error class.

Using function getRestHttpResponse(), you get access to the HTTP response object and can set the error details:

Code Block
local response = getRestHttpResponse();
set response.responseObject = <my error object>;
set response.httpStatus = <HTTP status code>;

Assign the error object and a HTTP status code that corresponds to the error. This information will be returned via the HTTP response.

Multiexcerpt include
MultiExcerptNameRESTErrorCodeAndMessage
PageWithExcerptDefining a REST Service Interface

In the support manager example, if user does not provide a support case id with the REST call, the implementation is as follows:

Error Handling for Specific Error Classes

If you defined a specific error class or Blob (Bridge 7.1.0) for a specific HTTP status code as described on Defining a REST Service Interface, you can use the same way as described above to provide the error details to the response. Provide the error details to an instance of the specific error class or Blob and provide the error class to the response object.
Look at activity Handle Authorization Errors of the support manager example:

...

  • Output: There can be no or exactly one output parameter via the response body. It has to be of complex type or of type Blob (Bridge 7.1.0). More output parameters can be specified via the HTTP headers.

The E2E Bridge supports JSON and XML content types, whereas JSON is the default if no divergent content type is specified. For more information on the supported content types, refer to Calling REST Services.

...

Parameter id is a rest parameter that comes with the resource path. Its value is transferred automatically to the method parameter having the same name. Type conversion to types divergent to String is applied automatically by the E2E Bridge.

Figure: Specification of REST Parameter id - Input Method

...

Body parameters are transferred in the request body. Since there is only one body in a HTTP request, only one body-parameter can be defined for an method. Body parameters have to be of complex type.

Noteinfo
iconfalse

To be in line with the HTTP specification, body parameters are allowed for PUT, POST and PATCH requests only.

The form of the body should correspond to the content type coming with the request. At the moment, the E2E Bridge supports application/json and text/xml content types.
For more information on the supported content types, refer to Calling REST Services.

...

Parameter supportCase is a rest parameter of complex type that comes via the request body. Its value is transferred automatically to the method parameter. Type conversion is applied automatically by the E2E Bridge.

Figure: Specification of REST Parameter supportCase - Input Method

...

Query parameters are provided to the service via the standard query-string. It is appended to the path after the ? delimiter and key-value pairs are delimited by &, e.g. /support/supportcases/?status=in%20progress&customerName=Wishes%20unltd .
The E2E Bridge will ignore unknown parameters, known parameters will be decoded and passed to the method. It is not necessary to provide all possible parameters with the query-string - omitted parameters will be NULL or have the specified default value (see Attribute Specification).

...

Parameters status and customerName are rest parameters that come via the query-string. Their value is transferred automatically to the corresponding method parameters of the same name. Type conversion is applied automatically by the E2E Bridge.

Figure: Specification of REST Parameter status - Input Method

...