Skip to end of metadata
Go to start of metadata

Web elements specify outside facing REST API or HTML pages. This way you can expose any data or functionality, or your ORIGAM applications in a simple way.

If you need a WebService (SOAP) interface you can find a description under Web Services (SOAP) API.

Use Cases

The typical use cases for Web API/Pages are:

  • HTML pages for extranet access
  • JSON API for modern JavaScript (AJAX) applications
  • JSON API for mobile applications
  • XML API for integration with other enterprise systems

Common attributes

Every web api/page has the following common attributes.


Specifies under which URL the API will be available. The URL can contain placeholders inside curly brackets which denote parameters. The URL has to omit the initial '/'. See more below.

Naming Recommendation

It is a good practice to put all public facing API's under /public or /api/public URL. It is then easier to configure the web server for access to all public API's with a single setting.


Specifies which MIME Type the API will return. These will be mainly

  • text/html
  • text/xml
  • application/json

Dynamic MIME Type

You can also use a special question mark value "?" in case of File Download Page. In that case the MIME Type will be automatically set by the downloaded file extension (e.g. in case the downloaded file will have an extension .PDF the mime type will be automatically set to application/pdf).

JSON Conversion

In case of a Data Page you can easily return JSON data by simply specifying a MIME Type application/json. The data will automatically be converted to JSON format.

RolesEnter an application role name for controlling which users have access to this API. Enter a star (*) to allow a public access.
FeaturesEnter a feature name which needs to be turned on in order to access this API. If nothing is entered the API is always available.

Input Parameters

You can pass parameters to the internal handler in the following ways:

  • Parameters defined inside the URL
  • Query parameters
  • In the request body using POST request

Using a URL

The URL can contain just the plain information on which address the link will be accessible but it can also contain parameter definitions.


api/orders/listNo parameters. This API would list all orders.
api/orders/{orderId}orderId parameter is a part of the URL. This API would return all information about a single order.
api/orders/{orderId}/acceptorderId parameter is a part of the URL but there is an additional part after the parameter. This API would change a status of an order.

You can combine more than one parameter inside the API URL.

You will need to map these parameters to the internal parameters using Parameter Mapping.

Using Query Parameters

Parameters can be passed typically using query parameters, e.g. /api/orders/list?customerId=1234&date=2014-10-10.

These parameters do not have to be defined in the model but you will need to map them to the internal parameters using Parameter Mapping.

Using Request Body Parameters

Parameters can be also passed (typically for POST requests) int he request body using the application/x-www-form-urlencoded MIME type.

These parameters do not have to be defined in the model but you will need to map them to the internal parameters using Parameter Mapping.

Example HTTP request content: customerId=1234&date=2014-10-10


In order to use API's you might need to configure the web server.

See also


  • No labels