
Within the REST library, the content of an HTTP request or response can be accessed over the IF_REST_ENTITY interface. A reference to this interface can be obtained from instances of CL_REST_REQUEST and CL_REST_RESPONSE by calling method IF_REST_MESSAGE~GET_ENTITY.
The REST library offers a small set of entity providers (see ABAP package SREST_EXT) which offer serialization and deserialization features for specific content types (for example, application/x-www-form-urlencoded).
It is possible for a REST application to write its own entity providers by deriving from class CL_REST_ENTITY_PROVIDER. The method WRITE_TO is of main interest in this case because it sets the formatted data in the REST entity passed into this method.
Whether it is better to
Either perform a manual serialization or deserialization of the business data (for example, by simple transformations) and setting the content in a REST entity directly, or
Or to write an own entity provider for serialization or deserialization
depends on the REST application's use case. Complex frameworks (like OData) benefit from own entity providers while small REST applications (where each resource could be serialized differently) may better choose the first option.
Use cases for entity providers:
Serialization scenarios For serialization purposes each entity provider is first created and the data is set in it for later serialization. These data can be of any type or format and can be set either with extra setter methods (e.g. SET_ENTITY_HEADER, SET_CONTENT_TYPE) or directly with the constructor (e.g. accepting an IF_REST_ENTITY object). For the final serialization the IF_REST_ENTITY_PROVIDER~WRITE_TO method is called with an entity with interface IF_REST_ENTITY.
Deserialization scenarios For deserialization the entity provider needs a setter or appropriate constructor to inject the entity set to be deserialized and getter methods to publish the data extracted from the REST entity.
IF_REST_ENTITY
The interface IF_REST_ENTITY provides methods for accessing data from an HTTP content:
Settings for: content type, language, compression, location
Expiration and modification date
Content header fields
Content as binary data or text data.
CL_REST_ENTITY
Implementation of interface IF_REST_ENTITY.
IF_REST_ENTITY_PROVIDER
Interface IF_REST_ENTITY_PROVIDER defines a basic set of methods which should be implemented by an entity provider. These methods are for setting and getting ETAG's, header fields and (very important) the WRITE_TO method to write the information within this entity provider into a REST entity using different method of the REST entity interface IF_REST_ENTITY (SET_BINARY_DATA, GET_BINARY_DATA, SET_STRING_DATA, GET_STRING_DATA).
CL_REST_ENTITY_PROVIDER
Class CL_REST_ENTITY_PROVIDER is the default implementation of interface IF_REST_ENTITY_PROVIDER. The class contains basically only a table attribute for storing the header field values, as well as method implementations for getting/setting header fields.
The ETAG is also stored as header field ETag
CL_REST_FORM_DATA
Converts HTTP content formatted as mime type application/x-www-form-urlencoded into a list of form fields and vice versa.
For serialization, a CL_REST_FORM_DATA instance needs to be created and the form fields can be set with the SET_FORM_FIELD method. Afterwards the WRITE_TO method can be used to write the form fields into an entity set.
For deserialization, the constructor of CL_REST_FORM_DATA needs to be called with an entity set. The methods GET_FORM_FIELD, GET_FORM_FIELDS and HAS_FORM_FIELD form fields can be used to read the deserialized data.
For more information about application/x-www-form-urlencoded refer to http://www.w3.org/Protocols/rfc2616/rfc2616.html.
CL_REST_MP_FORM_DATA
The CL_REST_MP_FORM_DATA extends the CL_REST_FORM_DATA processor so that content of the mime type multipart/form-data can be processed. This mime type can be used for transferring simple HTML form field values (like application/x-www-form-urlencoded) as well as one or more files for file upload or download.
CL_REST_MP_FORM_DATA inherits from CL_REST_FORM_DATA and provides additional methods to set the files which should be serialized and to access the files which have been deserialized.
For more information about multipart/form-data refer to http://www.w3.org/Protocols/rfc2388/rfc2388.html.
CL_REST_HTTP_REQ_PROV
Converts an HTTP content formatted as mime type application/http into to a valid REST request object and vice versa. Pay attention to the content formatting because any incorrect content leads to an empty HTTP request when deserializing (for example, missing or additional empty lines). A use case for this method is in multipart request processing (see Multipart Request).
For serialization set the REST request with method SET_REQUEST and call WRITE_TO with an entity provided (interface IF_REST_ENTITY) to serialize the request.
For deserialization use the entity with the HTTP content as input for the constructor of CL_REST_HTTP_REQ_PROV and obtain the document with help of the GET_REQUEST method (an object with interface IF_REST_REQUEST).
For more information about application/http refer to specification HTTP 1.1: http://www.w3.org/Protocols/rfc2616/rfc2616.html
CL_REST_HTTP_RESP_PROV
Converts an HTTP content formatted as mime type "application/http" into a valid REST response object and vice versa. Pay attention to the content formatting because any incorrect content leads to an empty HTTP request when deserializing (for example, missing or additional empty lines). A use case for this method is in multipart request processing (see Multipart Request).
For serialization set the REST response with method SET_RESPONSE and call WRITE_TO with an entity provided (interface IF_REST_ENTITY) to serialize the response.
For deserialization use the entity with the HTTP content as input for the constructor of CL_REST_HTTP_RESP_PROV and obtain the document with help of the GET_RESPONSE method.
For more information about application/http refer to the HTTP 1.1 specification: http://www.w3.org/Protocols/rfc2616/rfc2616.html.