In PAS for OpenEdge, transports handle HTTP requests and are built into the default ROOT (oeabl.war) application. Transports handle requests from clients that use any one of those protocols for communication with a web server.

Transports use reserved URLs to deliver different types of web services. The supported transports and their assigned URLs are described in the following table:
Transport Description URL Path Example URLs
APSV Handles ABL clients, Java and .NET Open Clients requests. /apsv

APSV code deployed to the ROOT application:

http://localhost:8810/apsv

APSV code deployed to an ABL web application other than ROOT (in this example, called financeApp):

http://localhost:8810/financeApp/apsv

Note: The APSV connection to PAS for OpenEdge is specified in the -sessionModel connection parameter argument in the ABL client application. For more information, see Connecting to a PAS for OpenEdge instance and Connection parameters argument in Application Development with PAS for OpenEdge.
REST Handles REST requests. /rest

REST service deployed to the ROOT application:

http://localhost:8810/rest/customerSvc/Customer

REST service deployed to an ABL web application other than ROOT (in this example, called financeApp):

http://localhost:8810/financeApp/rest/customerSvc/Customer

For more information about developing REST services, see Develop an ABL service using the REST transport in Develop ABL Services.
SOAP Handles SOAP 1.1 requests. /soap

SOAP service deployed to the ROOT application:

http://localhost:8810/soap/

SOAP service deployed to an ABL web application other than ROOT (in this example, called financeApp):

http://localhost:8810/financeApp/soap/

For more information about developing SOAP services, see Develop an ABL service using the SOAP transport in Develop ABL Services.
WEB Handles REST, classic WebSpeed, and HTTP requests. Offers the option to modernize your application with WebHandlers. /web

Web service deployed to the ROOT application:

http://localhost:8810/web/customerSvc/Customer

Web service deployed to an ABL web application other than ROOT (in this example, called financeApp):

http://localhost:8810/financeApp/web/customerSvc/Customer

The Web transport also supports using Progress Data Object (PDO) services, which are also indicated in the URI. This is shown in the following example:

http://localhost:8810/web/pdo/customerSvc/Customer

For more information, see the Develop a Progress Data Object Service in Develop ABL Services.

Note: It is not possible to remove the transport name from the URL path.
Note: Because a PAS for OpenEdge instance can contain one or more ABL web applications, if you are referencing an application other than the ROOT application, the URL path is preceded by the application name (for example, webapp_name/web).

ABL and web services

Additional information about ABL and web services:

  • ABL services are exposed using URI.
  • ABL services are grouped by transport, which is a path segment in the URI, for example, http://localhost:8810/webapp-name/rest.
  • ABL services are represented by a .paar file (REST transport), .wsm file (SOAP transport), or a WebHandler (WEB transport). APSV services must be moved to the PROPATH.
  • Transports can be secured independently. ABL services contribute authorization information to the OpenEdge ABL web application. For example, you can secure a transport URI so that it can only be accessed by an authenticated user with specific roles.
  • ABL services need service interfaces (.p or .cls files). Service interfaces are intended to translate input (HTTP messages) into ABL business logic calls, and the output of those calls back into HTTP. Service interfaces can also deal with error handling or perform additional authorization.
  • For more information, see Deployment artifacts and Develop ABL Services.