Show TOC

Background documentationClasses and Interfaces for Client Implementations Locate this document in the navigation structure

 

IF_REST_CLIENT

The IF_REST_CLIENT interface defines methods which are used on the REST client side.

These methods are for:

  • setting request header fields,

  • getting response header fields,

  • getting content and response status,

  • creating a REST entity for holding the content to be send and

  • releasing the ABAP session when communicating with an ABAP application server (method CLOSE).

Additionally, the IF_REST_RESPONSE interface is covered by this interface to define the HTTP methods HEAD, GET, DELETE, OPTIONS, POST and PUT.

Note Note

There is no need to manually create a REST request. The request header fields can be set directly on the Client object and a REST entity to store the content is created with the method IF_REST_CLIENT~CREATE_REQUEST_ENTITY.

End of the note.

To define the HTTP method a REST client class calls the appropriate HEAD, GET, DELETE, OPTIONS, POST or PUT method and retrieves response information via methods GET_RESPONSE_ENTITY, GET_RESPONSE_HEADER and GET_RESPONSE_HEADERS.

CL_REST_HTTP_CLIENT

The class CL_REST_HTTP_CLIENT implements a REST client for calling REST based web services via HTTP. A correctly parameterized ICF HTTP client is required as constructor parameter to create a CL_REST_HTTP_CLIENT instance. This HTTP client then is used for all HTTP requests.

For an example of how to use an ICF HTTP client together with a REST client refer to the REST Tutorial of this documentation.

CL_REST_LOCAL_CLIENT

The CL_REST_LOCAL_CLIENT class can be used to test REST services locally without any need to setup a HTTP communication. The constructor of this class just needs reference to the REST application class to be called, which should be called by the REST client.

The constructor contains these input parameters:

  • The REST application class,

  • optionally a REST context can be passed to the "server side" (actually the local REST application),

  • optionally a path of an ICF node (input parameter IV_ICF_NODE) can be set to tell the REST router at which URI position the resource routing starts.

    This is a short example for using this ICF path parameter IV_ICF_NODE:

    When testing a URL like http://www.mycompany.com/sap/bc/rest_cars/Cars/47 with a REST application whose URI template is "/Cars/{ID: [0-9]+}", the locally called REST router needs to remove the so called script name "http://www.mycompany.com/sap/bc/rest_cars" (this is the part of the URI which is used for the request handling by the ICF framework) and uses the remaining part "/Cars/47" to locate the REST resource handling class (see Service Registration and Routing for more details).

    For local calls where no ICF is involved this path has to be set with the input parameter IV_ICF_NODE.