REST API Details
The REST framework enables you to model APIs conforming to the Resource Oriented Architecture (ROA) design. For example, you might model an API that serves to expose the web service data and functionality as a collection of resources. Each resource is accessible with unique Uniform Resource Identifiers (URIs). In your API, you expose a set of HTTP operations (methods) to perform on a specific resource and capture the request and response messages and status codes that are unique to the HTTP method and linked within the specific resource of the API.
The API details view for a REST API displays the details of the API such as basic and technical information, resources and methods, API mocking details, and specifications. You can also view the scopes associated, policies enforced, registered applications and the API-specific analytics.
The table lists the API details displayed for the API
Field | Description |
Basic information | Displays the information about the API, such as Name, Version, Owner of the API, the teams that the API is assigned to, status of the API whether its is Active or Inactive, the maturity state of the API, the date on which the API was created and a brief description of the API. |
Technical information | Displays the following endpoints of the API:  Native endpoints. Gateway endpoints. Displays these endpoints when the API is deployed to a gateway. Microgateway endpoints. Displays these endpoints when the API is deployed to a Microgateway. AppMesh endpoints. Displays these endpoints when the API is deployed through AppMesh. Service Registry display name. Displays the name of the service registry where the API is deployed. |
Resources and methods | Displays a list of resources or methods available in the API sorted by resource/pathname. The list of resources are displayed in sorted order of the path names. Click each resource to view the corresponding HTTP methods, along with a summary. Below each of these methods, details such as parameters and response codes are displayed. |
API mocking | Details are visible only when API mocking is enabled. Displays a list of mocked responses for the operations in the API, custom IS service list and conditions along with its mocked response. |
Components | Displays the schemas defined at the API level. |
Documentation | Displays the definition of the API in different formats. |
Various tabs displayed in the API details page display the following details:
The
Scopes tab lists the scopes available for the API.
The
Policies tab displays the policies enforced for the API.
The
Mashups tab displays the mashups defined in the API.
The
Applications tab displays all the applications registered with the API.
The
Analytics tab displays the API-specific analytics for the time interval selected.
You can perform the following operations from the API details page:
You can enable API mocking by clicking the
Enable mocking button. If API mocking is enabled, you can disable it by clicking the
Disable mocking button. This option is available when the API is in the deactivated state.
You can update an API by importing from file or from URL by clicking the
Update button. This option is available when the API is in the deactivated state.
You can create a new version of the API by clicking the
Create new version button.
You can modify details of an API by clicking the
Edit button. This option is available when the API is in the deactivated state.
You can activate an API by clicking the
Activate button. If the API is already activated, you can deactivate it by clicking the
Deactivate button.
Microgateway endpoints
Microgateway endpoints are exposed in this section when one or more Microgateways start connecting to API Gateway with a particular API. When you activate the API, the routing to the connected Microgateway endpoints comes in effect. This means that when you call the API Gateway endpoint in the usual way, the request is directly routed to the Microgateway. If there are multiple Microgateways, the routing is done in a round-robin order to each of the participating Microgateways. The called Microgateway processes the request with all the defined policies.
AppMesh endpoints
The AppMesh endpoint gets exposed only for APIs created by AppMesh's APIfy operation. In an AppMesh context, Microgateway and the corresponding micro services are behind a Kubernetes service or a loadbalancer. When you activate the API, the routing to this AppMesh endpoint (depending on your Kubernetes service loadbalancer setting) comes in effect. This means that when you call the API Gateway endpoint in the usual way the request is directly routed to that endpoint.