Creating an Interface part to access a REST service

You define an EGL Interface part in a file that is made available to the requester of that service. The Interface part can be in the same EGL package or can be imported from a separate package.

An EGL Interface part includes one or more function prototypes, which are descriptions of how to write code to access a given service operation. A function prototype includes the operation name, parameters (if any), and a return type (if any). The prototype does not include the logic of the operation, which is available in the service only.

The Interface part of an EGL REST service is simpler than that for a non-EGL REST service.

Interface part for accessing an EGL REST service

This example shows an Interface part for accessing an EGL REST service; the example includes a single function prototype:
Interface EmployeeService
   Function GetEmployeeDetail(employeeCode STRING IN, 
                              employeeSalary FLOAT OUT, 
                              employeeStatus STRING INOUT) 
            returns(myEmployeeRecordPart);
end

You can specify a variety of EGL data types and can use the modifiers IN, OUT, and INOUT.

To create the Interface part:
  1. In the Project Explorer, right click the EGL file that defines the service
  2. Click EGL Services > Extract EGL Interface.
  3. In the New EGL Interface part window, specify the appropriate details and click Finish

Interface part for accessing a third-party REST service

This example shows Interface part for accessing a third-party REST service:
Interface WeatherForecast
   Function GetWeatherByZipCode(zipcode string in) returns(myRecordPart)
      {@GetRest{uriTemplate="/GetWeatherByZipCode?zipCode={zipcode}",
                requestFormat = JSON,
                responseFormat = JSON}};
end

If the purpose of the Interface part is to describe the operations that are available in a third-party REST service (not an EGL REST service), you must specify a complex property for each function prototype. The name of the property indicates the HTTP verb that is used to access the service: the property name is @GetREST for GET, @PostREST for POST, @PutREST for PUT, and @DeleteREST for DELETE. Those complex properties are referred to as the @xREST properties because the same three property fields are in each, as described in the @xREST properties section of this topic.

In the service-invocation statement that is used to access a third-party REST service, the argument that is passed to a given function parameter has one of two purposes:
  • In most cases, the argument provides a value that the requester includes in the URI. This usage is shown later in this topic, in the description of the @xREST properties. Those values are not passed to the service logic; they are values that are embedded in the URI. In particular, if the property is @GetREST, all of the arguments that are assigned to the function parameters are used to construct the URI.
  • In the case of one argument (at most), the argument is a representation that is processed by the service; for example, a record that contains values used to create a database-table row. Here are details:
    • If the property is @PostREST or @PutREST for a given operation, the argument must be present, and the related parameter is called the representation parameter.
    • The argument also might be required if the property is @DeleteREST; the need for such an argument depends on the service provider.

For details about the data types valid for a given parameter, see “Specifying function parameters for service access.”

You do not need to create an Interface part. Instead, you can use IRest, which is an Interface part that is provided for you and that can be the basis of a variable that is used to access a third-party REST service. For more information about that Interface part, see “Using a provided Interface for REST-service access.”

@xREST properties used for third-party REST services

Each of the @xREST complex properties has the uriTemplate, requestFormat, and responseFormat fields:

uriTemplate
A string (called a template) that in most cases outlines a relative URI, which identifies the last qualifiers in the URI that are used to access the service. For background information, see “REST for the developer.”
The first URI qualifiers, the base URI, are specified in one of three ways:
  • When you declare a variable that is based on the Interface part, you can set the base URI. In this case, the base URI is set at development time, and no change is possible at configuration time or run time. This usage is simple and fast, but inflexible.
  • Alternatively, when you declare a variable based on the Interface part, you can identify an entry in a deployment descriptor. In this case, an initial value for the base URI is in the deployment descriptor, and at configuration time, a code installer can change that value.
  • You can run the serviceLib.setServiceLocation function to change the value of the base URI at run time, regardless of how you specify an initial value.

If you do not set the base URI, the value of uriTemplate includes the complete URI.

In most cases, the value of the uriTemplate property has two aspects:

  • The value of the uriTemplate property can include a constant value. Those characters are present either in or after every URI that is used to access the function. In the previous example, the value of uriTemplate includes a query variable, and the constant value is as follows:
       /GetWeatherByZip?zipcode= 
    If the example is changed to include a path variable instead of the query string, the constant value is as follows:
       /GetWeatherByZip/
  • The value of the uriTemplate property can include path variables and query variables. The previous example includes a single query variable:
       {zipcode}
    For the original example with a query string, here is a relative URI and value that are used to access the service:
    /GetWeatherByZip?zipcode=02135
    If the template includes a path variable instead of a query string, here is a relative URI:
    /GetWeatherByZip/02135

    The EGL runtime code automatically completes a URI encoding on each substitution value that is specified in a service invocation statement, with one exception.

    For example, if your service-invocation statement indicates that the value for a given substitution variable is "Jeff Smith", the EGL runtime code converts the string to "Jeff%20Smith" so that the URI is valid. However, if the value of a substitution value begins with http, the EGL runtime code does no URI encoding because the service-invocation statement is specifying an argument that provides a complete URI. If you are responsible for URI encoding, review the documentation on the serviceLib.convertToURLEncoded system function.

The default value of the uriTemplate field is an empty string so that, by default, you can specify the complete URI by setting the base URI.

requestFormat
A value that indicates the format of the representation sent to the service:
  • XML, to indicate that the format is Extensible Markup Language
  • NONE, to indicate that the representation is a string (or a value that is compatible with a string) and is sent as is
  • JSON, to indicate that the format is JavaScript™ Object Notation
  • FORM, to indicate that the format is form data, which is composed of argument-value pairs. In the following example, each parameter is separated from the next by an ampersand (&):
    division=Consumer&dept=Sales
If the representation is a record, the following statements apply:
  • The default value of requestFormat is XML.
  • JSON is also valid.
  • FORM is valid only if every field in the record is of type STRING or of a type that is assignment-compatible with STRING. FORM is not valid if the record references another record.
responseFormat
A value that indicates the format of the representation returned to the requester:
  • XML, to indicate that the returned representation is in XML format
  • NONE, to indicate that the returned representation is a string
  • JSON, to indicate that the returned representation is in JSON format

If the return value in the Interface part function prototype is a string or a value that is compatible with string, the default value of responseFormat is NONE, which is the only valid format. If the return value is a record, the default value of responseFormat is XML, and JSON is also valid.

You can specify an @xREST property without assigning values to the property fields:
Interface IEmployeeService
   Function GetEmployeeDetail() returns(myRecordPart)
      {@GetRest{}};
end
The lack of property fields indicates these behaviors:
  • You must provide the complete REST service URI—such as http://www.ibm.com/myservice—in some way, without providing detail in the Interface part. For details about the three choices for specifying the base URI, see the description of uriTemplate in this topic.
  • If the representation parameter (or, for @GetREST, the return value) is a string, the EGL runtime code does no conversion. You must handle the conversion and can use any of the following functions for that purpose:
    • serviceLib.convertFromJSON
    • serviceLib.convertToJSON
    • XMLLib.convertFromXML
    • XMLLib.convertToXML
  • If the representation parameter is a record, the EGL runtime code converts the related argument to Extensible Markup Language (XML) format.
  • For @GetREST, if the return value is a record, the EGL runtime code converts that record from XML format.
.

Feedback