Creating REST Services in Caché
Creating REST Services
[Home] [Back] [Next]
InterSystems: The power behind what matters   
Class Reference   
Search:    

This chapter describes how to build Caché REST services using the %CSP.REST class. This class enables you to create a REST service.

This chapter contains the following sections:
The %CSP.REST Class
The %CSP.REST class, which is a subclass of %CSP.Page allows you to implement REST services. It provides the ability to:
To implement a REST service, you extend the %CSP.REST class. Your extension of the class provides the URLMap, can optionally set the UseSession parameter, and provides class methods to perform the REST operations. You can define more than one subclass of %CSP.REST in a namespace. Each subclass that has its own entry point must have its own CSP web application. You define the CSP web application and specify its security on the Management Portal’s [Home] > [Security Management] > [Web Application] page, which you can access by clicking System Administration, Security, Applications, and Web Applications. When you define the CSP web application, you set the Dispatch Class to the name of the custom subclass of %CSP.REST and specify the first part of the URL for the REST call as the name of the application.
Creating the URL Map for REST
The XDATA UrlMap associates the REST call with the method that implements the service. It can either directly send the call to a method based on the contents of the URL or it can forward the call to another subclass of %CSP.REST based on the URL. If the web application is handling a small number of related services, you can send the call directly to the method that implements it. However, if the web application is handling a large number of disparate services, you can define separate subclasses of %CSP.REST, each of which handles a set of related services. Then the subclass of %CSP.REST that handles the web application simply forwards the REST call to the appropriate subclass.
If the subclass of %CSP.REST is sending the call directly to the methods, the URLMap contains a Routes definition that contains a series of Route elements. Each Route specifies a class method to be called for the specified URL and HTTP operation. Typically REST uses the GET, POST, PUT, or DELETE operations, but you can specify any HTTP operation. The URL can optionally include parameters that are specified as part of the REST URL and passed to the specified method as parameters.
If the subclass of %CSP.REST is forwarding the calls to other subclasses of %CSP.REST, the UrlMap contains a Routes definition that contains a series of Map elements. The Map statement forwards all calls with the specified prefix to its associated %CSP.REST subclass, which will then implement the behavior. It can implement the behavior by sending the call directly to a method or by forwarding it to another subclass.
Caché compares the incoming REST URL with the Route URL property or the Map Prefix property. It starts at the first Route or Map element and continues to test each following element until it finds a match. Once it finds a match it either sends the incoming call to the call specified in the Route or forwards the URL to the class specified in the Map. In both cases, it ignores any elements in the Routes after the matching element; consequently, the order of the elements in the Routes is significant. If an incoming URL could match multiple elements of the Routes, Caché uses the first matching element and ignores any subsequent possible matches.
URLMap with Route Elements
Caché compares the incoming URL and the HTTP request method to each Route element in Routes. It calls the method specified in the first matching Route element. The Route element has three parts:
For example, the DocServer sample defines the following Route:
XData UrlMap
{
<Routes>
  <Route Url="/echo" Method="POST" Call="Echo" Cors="false" />
This specifies that the REST call will end with /echo and use the POST method. It will call the Echo class method in the REST.DocServer class that defines the REST service. The Cors property is optional, has a value of "true" or "false" and controls CORS header processing. See Configuring a REST Service to Use CORS for details on using CORS.
The complete REST URL consists of the following pieces:
For the preceding example, the complete REST call as shown by a TCP tracing utility is:
POST /csp/samples/docserver/echo HTTP/1.1
Host: localhost:57772
The following Route definition defines two parameters, namespace and class, in the URL:
<Route Url="/class/:namespace/:classname" Method="GET" Call="GetClass" />
A REST call URL starts with /csp/samples/docserver/class/ and the next two elements of the URL specify the two parameters. The GetClass method uses these parameters as the namespace and the class name that you are querying. For example, the REST call:
http://localhost:57772/csp/samples/docserver/class/samples/Cinema.Review
calls the GetClass method and specifies “samples” and “Cinema.Review” as the parameter values. The definition of the GetClass method starts with:
/// This method returns the class text for the named cache class
ClassMethod GetClass(
  pNamespace As %String,
  pClassname As %String) As %Status
{
You can define a different method for each HTTP request method for a single URL. For example, you could define the following:
<Route Url="/request" Method="GET" Call="GetRequest" />
<Route Url="/request" Method="POST" Call="PostRequest" />
With these routes, if the URL /csp/samples/docserver/request is called with an HTTP GET method, the GetRequest() method is invoked. If it is called with an HTTP POST method, the PostRequest() method is invoked. In the DocServer sample, both HTTP request methods are handled by a single Call method. The Route definitions in the sample is
<Route Url="/request" Method="GET" Call="Request" />
<Route Url="/request" Method="POST" Call="Request" />
In this case, the Request() method handles the call for either a GET or a POST operation. If this method needs to distinguish between a GET and a POST operation, it can do this by examining the CSP request object, which contains the text of the URL.
If you want to separate the code implementing the REST services from the %CSP.REST dispatch code, you can define the methods implementing the REST services in another class and specify the class and method in the Call element.
Note:
The :parameter-name syntax for defining parameters in the URL is implemented using regular expressions. Each segment specified as :parameter-name is converted to a matching group in the regular expression. In most cases this format provides enough flexibility to specify the REST URL, but advanced users can use the regular expression format directly in the route definition. The URL must match the regular expression and each matching group, which is specified by a pair of parentheses, defines a parameter to be passed to the method. The :parameter-name syntax is translated to a “([^/]+)” within the regular expression. This syntax matches any character except the / (slash). So the GetClass sample, which is Url="/class/:namespace/:classname", is equivalent to:
<Route Url="/class/([^/]+)/([^/]+)" Method="GET" Call="GetClass" />
where there are two matching groups that specify two parameters. If you wanted a component of the URL to have the values: “Direction_Up” or “Direction_Down”, you could define the route map as follows:
<Route Url="/controlVehicle/Direction_(Up|Down)" Method="POST" Call="Move" />
With this definition, the parameter would have either the value “Up” or “Down” since that is the value of the matching group.
URLMap with Map Elements
Caché compares the incoming URL to the prefix in each Map element in Routes. It forwards the incoming REST call to the %CSP.REST subclass specified in the first matching Map element. That class processes the remainder of the URL, typically calling the method that implements the service. The Map element has two parts:
Consider the following URLMap that contains three Map elements.
XData UrlMap
{
  <Routes>
    <Map Prefix="/coffee/sales" Forward="MyLib.coffee.SalesREST"/>
    <Map Prefix="/coffee/repairs" Forward="MyLib.coffee.RepairsREST"/>
    <Map Prefix="/coffee" Forward="MyLib.coffee.MiscREST"/>
  </Routes>
}
This UrlMap forwards the REST call to one of three subclasses of %CSP.REST: MyLib.coffee.SalesREST, MyLib.coffee.RepairsREST, or MyLib.coffee.MiscREST.
The complete REST URL to call one of these REST services consists of the following pieces:
For example, the following REST call:
http://localhost:57772/coffeeRESTSvr/coffee/sales/reports/id/875
matches the first map with the Prefix /coffee/sales and forwards the REST call to the MyLib.coffee.SalesREST class. That class will look for a match for the remainder of the URL, "/reports/id/875".
As another example, the following REST call:
http://localhost:57772/coffeeRESTSvr/coffee/inventory/machinetype/drip
matches the third map with the Prefix /coffee and forwards the REST call to the MyLib.coffee.MiscREST class. That class will look for a match for the remainder of the URL, "/inventory/machinetype/drip".
Note:
In this URLMap example, if the Map with the Prefix="/coffee" was the first map, all REST calls with /coffee would be forwarded to the MyLib.coffee.MiscREST class even if they matched one of the following Map elements. The order of the Map elements in Routes is significant.
Specifying the Data Format
You can define your REST service to handle data in different formats, such as JSON, XML, text, or CSV. A REST call can specify the form that it expects data it is sending by specifying a ContentType element in the HTTP request and can request the return data format by specifying an Accept element in the HTTP request.
In the DocServer sample, the GetNamespaces() method checks if the REST call requested JSON data with the following:
If $Get(%request.CgiEnvs("HTTP_ACCEPT"))="application/json"
Using a CSP Session with REST
The UseSession parameter controls whether Caché uses a new CSP session for each REST service call or preserves a CSP session across multiple REST service calls. One of the goals of REST is to be stateless, that is no knowledge is stored on the server from one REST call to the next. Having a CSP session preserved across REST calls breaks the stateless paradigm, but there are two reasons why you might want to preserve a CSP session:
To enable using a single CSP session over multiple REST calls, set the UseSession parameter to 1 in your subclass of %CSP.REST that is defined as the dispatch class for a CSP web application. For example:
Class REST.MyServices Extends %CSP.REST { 
Parameter UseSession As Integer = 1
Authentication in REST
If your REST service is accessing confidential data, you should use authentication. You can use either of the two following forms of authentication: