Try OpenEdge Now
skip to main content
Web Services
Creating OpenEdge REST Web Services : Data Object Services : URIs for accessing Data Object Web applications, Services, and resources : Data Object URIs for testing resources from REST clients
 
Data Object URIs for testing resources from REST clients
After first developing and publishing Data Object Services, you might want to test the Data Object resources they provide before you create a mobile or Web app to access them using JSDOs. You can do this using various REST clients, such as the Postman REST Client, that allow you to access Data Object operations directly as REST resources. (Remember that a single Data Object resource can encapsulate several Data Object operations, each of which is accessed by a unique REST resource.) To test these REST resources using a REST client, you need to know the exact absolute REST URI of the REST resource that accesses each Data Object operation.
When you create Data Object resources and the Data Object Services to contain them, you assign a relative URI (or use the default) for each Data Object Service and resource that you define. In addition, each operation that you define for a Data Object resource is assigned a unique relative URI as part of the resource annotations that you add to the ABL Business Entity that implements the Data Object resource.
The absolute URI to access a given Data Object operation is a concatenation of all these relative URIs with the absolute root URI of the deployed Web application, as specified using the following syntax:
Syntax
scheme://host:port/web-app-name/transport/service-name/resource-name[op-element]
scheme//host:port
The beginning of every absolute URI, as described previously (see Data Object URIs for client app access).
/web-app-name
The relative URI for the Data Object Web application, where web-app-name is the name of the Web application that contains your Data Object Service or Services, and serves as the root URI for all Data Object resources provided by the Web application. By default, this is the file name of the WAR file that you use to publish or deploy the Data Object Services to your OE Web Server or PAS for OpenEdge, and it is also the name of the Web server folder in which all of the Web application's Data Object Services and Web resources (including Data Service Catalogs) are deployed.
During development, by default, Progress Developer Studio for OpenEdge publishes each Data Object Service defined for a project with the file name of its own WAR file set to name of the Data Object Service. For production deployment, you can export and deploy multiple Data Object Services in a single WAR file, which by default has the name of the Classic or PAS for OpenEdge Server project. Note that during production deployment, a Web administrator can change the file name of the WAR file and the name of the Web application to a different value.
Note: During development, you cannot change the name of the WAR file that Developer Studio publishes for each Data Object Service in a project.
/transport
The relative URI for the transport, which can be one of the following, depending on the service provider:
*/rest — A REST transport for a Data Object Service created using an OpenEdge Server project in Developer Studio with a REST RPC service provider on PAS for OpenEdge, or on an OE Web Server or generic Tomcat server accessing the classic OpenEdge AppServer.
*/web/pdo — A WEB transport for a Data Object Service created using an OpenEdge Server project in Developer Studio with a WebHandler service provider on PAS for OpenEdge.
The PAS for OpenEdge WEB transport reserves /web/pdo, and Progress Software recommends that you do not use the /web/pdo URI in your own application URL space.
This is a literal relative URI defined by OpenEdge that identifies the root for all OpenEdge resources provided by the Data Object Web application.
Note: Unlike the /static relative URI that identifies the physical location of most static Web resources, such as Data Service Catalogs and Web pages, the /web-transport URI does not represent a physical folder on the Web server, but simply identifies a dynamic point in a URI where the relative URI to a given Data Object resource begins.
/service-name
The relative URI for the Data Object Service, where service-name defaults to the name you assign the service when you define it in Developer Studio. You can also assign a different name for the URI at the time the Data Object Service is created.
/resource-name
The relative URI for the Data Object resource, where resource-name defaults to the name you assign the resource when you define it in Developer Studio. You can also assign a different name for the URI at the time the Data Object resource (Business Entity) is created.
op-element
A relative URI or a URI query parameter that is specified to identify specific Data Object resource operations, as follows:
*?filter=filter-string — For the Read operation, this URI query parameter identifies the INPUT filter parameter value passed to the implementing ABL routine, where filter-string is a string value you type, quoted if necessary.
*/routine-name — For an Invoke or Submit operation, where routine-name, by default, is the case-sensitive name of the ABL routine that implements the specified Invoke or Submit operation, or any other value that you annotate for the relative URI of an Invoke or Submit operation routine that uniquely identifies and distinguishes the routine from any other that is defined for the resource.
Note that all other INPUT (and the input side of INPUT-OUTPUT) parameters passed to the implementing ABL routines of Data Object operations are passed in the body of the HTTP request. For more information, see Using a REST client to execute a Data Object operation.