API Management
Version 24.3.9106
Version 24.3.9106
API Management
You can browse your APIs and manage access to them in the administration console. Click API on the navbar 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.