Show TOC

Background documentationService Registration and Routing Locate this document in the navigation structure



This interface is part of the Internet Communication Framework (ICF). Any class implementing IF_HTTP_EXTENSION can be registered in the ICF service repository for a URL to build an ICF service.

The single method HANDLE_REQUEST of the interface is called whenever the ICF processes an HTTP request that matches the URL. Classes implementing this interface are usually called HTTP handler or ICF handler.

For more information about registering ICF services, see the ICF documentation.


The interface IF_REST_APPLICATION declares the GET_ROOT_HANDLER method. This method must be defined by any REST application and MUST return an instance of type IF_REST_HANDLER. By default this is an instance of class CL_REST_ROUTER containing the possible routes to the REST resources published by the applications.



The CL_REST_HTTP_HANDLER is the base class for all REST applications. A new REST application can be created by implementing a new subclass of CL_REST_HTTP_HANDLER and by implementing the method IF_REST_APPLICATION~GET_ROOT_HANDLER to define the resources which build the REST application. This subclass is often called Application Class and can be used directly in the ICF service repository.


The CL_REST_HTTP_HANDLER is an abstract class that serves two purposes, Integration into Internet communication framework and Basis class for REST applications.

  • Integration into Internet communication framework

    Any HTTP server application on the ABAP stack must use the ICF and therefore needs to implement an ICF service with a service URL and an ICF Handler class to be callable by HTTP. This applies also to all REST applications. But instead of having all REST applications writing their own ICF service handler (which would mean implementing method IF_HTTP_EXTENSION~HANDLE_REQUEST) the REST library provides a generic REST HTTP handler inside class CL_REST_HTTP_HANDLER. This implementation works together with the CL_REST_ROUTER to process the REST request and improves consumability.

  • Basis class for REST applications

    The generic REST HTTP handler uses the ICF objects to collect all information required to select the REST resource identified by the request URL and invokes the resource handler. In order to do this, a list of all available resources and resource paths to identify them, the "router information", is required. This router information is passed to the REST HTTP handler with help of the interface IF_REST_APPLICATION which contains a method GET_ROOT_HANDLER. This method must be defined by each REST application to create and return an instance of CL_REST_ROUTER which stores the resource path and the resource classes.

Note Note

To make use of these two functions a new REST application just has to derive a new subclass from CL_REST_HTTP_HANDLER and implement the method GET_ROOT_HANDLER.

End of the note.


This interface is used to call all classes that can process a REST request. There are currently only the classes CL_REST_ROUTER and CL_REST_RESOURCE that can implement this interface. Although there is no need for a REST application to implement this interface (especially the HANDLE method), it is used as the input parameter type for various methods.


The rest router is responsible to store resource handler classes and the REST URI templates associated to them, as well as providing the algorithm for selecting and calling the appropriate resource identified by a REST route.

Usually the router is instantiated in the GET_ROOT_HANDLER method in the Application Class. Resource classes and their URI templates can be attached with the ATTACH method. This ATTACH method uses the URL template and a class name as input. It is required that the class named with t is required that the class named with <class name> implements the IF_REST_RESOURCE interface to be proper callable. Be aware that during design time when activating the coding there is no possibility to verify the class name, so be careful and check the name twice.

Optionally a parameter list can be passed to attach a function. While processing the REST request these parameters are passed to the constructor of the resource handler class.

The following picture gives an overview of the control flow on the server side:

This graphic is explained in the accompanying text.

Control Flow on the Server Side


The interface IF_REST_RESOURCE defining the methods GET, POST, PUT, DELETE, HEAD and OPTIONS which reflect the six HTTP methods. It is not required to implement this interface solely by the REST application developer, but inherit it from CL_REST_RESOURCE instead.


The class CL_REST_RESOURCE is the designated base class for all REST resources. The intention is that any application resource class inherits from this class and overwrites some methods to implement application resource specific behavior.


  1. Implements the IF_REST_HANDLER interface. So all derived classes of CL_REST_RESOURCE can be attached at the REST router together with a URI template.

  2. Implements the IF_REST_RESOURCE interface with default GET, POST, PUT, ... methods implementations which raise a 405 ("Method not allowed") HTTP response code.

  3. Contains a default implementation of IF_REST_HANDLER->handle method for dispatching the request to the appropriate IF_REST_RESOURCE method.

  4. Offers a default conditional handling implementation.

The following instance attributes can be accessed in subclasses:


    Reference to the interface IF_REST_REQUEST which contains all available data from the incoming(server side) or outgoing(client side) HTTP request.


    Reference to the interface IF_REST_RESPONSE which contains all available data from the outgoing (server-side) or incoming (client-side) HTTP request.


    Reference to IF_REST_CONTEXT


    If set to ABAP_TRUE in the constructor the HANDLE method will perform a conditional handling.

    For more in depth information about conditional handling in the REST library refer to Integration of conditional handling in to the rest library.

Expected Semantic for overwritten methods on the server side:

  • GET

    Uses URI attribute and URI query parameter data from the MO_REQUEST object to select the correct application data (for example, from a database table or business object), serializes the application data and sets the serialized content on the MO_RESPONSE object.

  • POST

    Uses URI attribute and URI query parameter data from the MO_REQUEST as well as the request content to create new application data (for example, append to table, create business object instance).

  • PUT

    Uses URI attribute and URI query parameter data from the MO_REQUEST as well as the request content to update application data (for example, modify table entry or business object).


    Uses URI attribute and URI query parameter data from the MO_REQUEST so select and delete the application data.

  • HEAD

    Like GET, but the server must not return the content with the MO_RESPONSE object.


    Send back information about possible options/requirements which are associated with this resource (used rarely).