Version 24.2.9039

• Discovery
  • Service Document
  • Metadata URL
  • OpenAPI Definition
• Server Responses
• Rate Limiting
  • User-Specific Limits
• CORS

You can browse your APIs and manage access to them in the administration console. Click API on the navigation bar to view documentation and examples of accessing the API. Use the settings in the connector to manage resources, users, and server settings for your API.

This section contains topics related to managing your API.

Discovery

The application’s APIs are based on the OpenAPI specification, and are fully documented and discoverable. The APIs can be accessed from standard JavaScript, applications compliant with OpenAPI, or any application that supports the OData standard. The following sections show how to use these standards to discover the APIs.

Service Document

The service document is a simple listing of all the APIs in JSON format by default. The service document is returned from the service root, where all requests are made, including metadata discovery requests. The following is an example of the service root:

http://MyServer:MyPort/connector/MyAPIPortName/api.rsc/

To retrieve more detailed information, make a request to the metadata URL.

Metadata URL

The application exposes the capabilities of its APIs to OData consumers through the OData metadata document URL. The metadata document is returned as XML and contains column data types, the key of the resource, and other information. You can access the complete metadata resource by appending $metadata to the service root, as shown in the following example:

http://MyServer:MyPort/connector/MyAPIPortName/api.rsc/$metadata

To access the metadata for a resource, append $metadata to the resource URL:

http://MyServer:MyPort/connector/MyAPIPortName/api.rsc/Cars/$metadata

OpenAPI Definition

OpenAPI (Swagger) definitions are generated for the data sources you surface through the application.

To obtain the Swagger definition, append $swagger to the service root, as shown in the following example:

http://MyServer:MyPort/connector/MyAPIPortName/api.rsc/$swagger

Server Responses

The following is a list of typical server responses to API resources and descriptions of when to expect such responses.

200 OK	The request was processed by the server without error.
201 Created	The request was successful and the specified resource was created by the server.
204 No Content	A request returns this status if the requested resource has a null value or the service applies a return=minimal preference.
400 Bad Request	The request was not understood or was missing required parameters.
401 Unauthorized	The user was not authenticated or authorized to access this resource.
403 Forbidden	Access is denied to this resource.
404 Not Found	The resource does not exist.
405 Method Not Allowed	The HTTP method specified is not allowed for this resource.
429 Too Many Requests	The user has sent too many requests in a given amount of time, or exceeded the maximum amount of concurrent requests.
501 Not Implemented	The server does not support the functionality required to fulfill the request. This response is returned when the server does not recognize the request method and is not capable of supporting it for any resource.

Rate Limiting

You can configure both per-user usage limits and server-wide defaults. See Default Rate Limits (Per User) for details on how to configure rate limiting

User-Specific Limits

To configure rate limits for an individual user, navigate to the User tab, select a user, and click Edit. You can configure the following options:

• Privileges: Select the HTTP methods the user is allowed to access: GET, POST, PUT/PATCH/MERGE, or DELETE. These correspond to SELECT, INSERT, UPDATE, and DELETE statements, respectively.
• Max. Requests: Enter the maximum requests per hour for this user. A value of 0 allows the user unlimited access per hour.
• Max. Concurrent Requests: Enter the maximum number of requests that can be sent simultaneously. A value of 0 allows the user unlimited simultaneous requests.

Note: User-specific rate limits override the server defaults. An empty value for one of the user settings uses the server default.

CORS

You can configure cross-origin resource sharing (CORS) on the Server tab. CORS allows browser-based clients to connect to Arc. Without CORS, browser-based scripts cannot connect to Arc because of the same-origin policy enforced by the browser. This policy restricts client-side scripts and documents from loading resources outside their origin. The origin of a script consists of the protocol, host, and port.

See CORS for details on how to configure CORS.