API interface architecture
The IBM® Telco Network Cloud Manager - Orchestration API is responsible for interactions with the operations available from IBM Telco Network Cloud Manager - Orchestration.
API interaction principles
Each of the major components within IBM Telco Network Cloud Manager - Orchestration are built as micro-services that use HTTP as the transport mechanism for requests and responses.
The IBM Telco Network Cloud Manager - Orchestration API uses a combination of REST style interfaces and RPC interfaces. The RPC-style interface is used to submit Intents to IBM Telco Network Cloud Manager - Orchestration. All other interfaces use a REST-style.
The IBM Telco Network Cloud Manager - Orchestration API is designed to provide a combination of REST and RPC interfaces. It does not always conform to all the details of the IETF RFC 7231 specification. However, the IBM Telco Network Cloud Manager - Orchestration API adheres to the spirit of the IETF recommendations.
Unless detailed otherwise, all message descriptions are in JSON format and must be submitted with
the HTTP content-type header of application/json. All dates conform to the ISO-8601
standard.
Supported HTTP request methods
| Method | Description |
|---|---|
| GET | The GET method requests a representation of the specified resource. Requests that use GET only to retrieve data have no other effect. |
| PUT | The PUT method requests that the enclosed entity is stored under the supplied URI. If the URI refers to an existing resource, it is modified; if the URI does not point to an existing resource, then the request is rejected. |
| POST | The POST method requests that the server accept the entity that is enclosed in the request as a new instance of the resource identified by the URI. |
| DELETE | The DELETE method removes the specified resource, if it exists. |
API Versioning
The IBM Telco Network Cloud Manager - Orchestration API does not support API versioning and has no plans to do so. The API is maintained to be compatible with earlier versions.
HTTP error response codes
| Code | Description |
|---|---|
400 – Bad Request |
The request contained invalid information, for example, an incorrect field, invalid value, or an inconsistent state on a dependent resource. The HTTP response body might contain a JSON message with further details of the specific issue. |
401 – Not Authorized |
The user or Client making the API request is not authorized to do so. Check the role configuration of the user or client who is making the request. |
404 – Not Found |
The requested endpoint cannot be found, or the Requested Entity cannot be found. |
409 - Conflict |
IBM Telco Network Cloud Manager - Orchestration is unable to process the request due to a conflict produced by some of the information supplied. For example, attempting to create two Resource Managers with the same name. |
415 – Unsupported Media Type |
The HTTP request payload has a Content-Type that is not supported by the IBM Telco Network Cloud Manager - Orchestration API. |
500 – Internal Server Error |
An internal error occurs. The HTTP response body might contain a JSON message with further details. For more information about the error, your system administrator can look at the logs. |
502 – Bad Gateway |
A remote system does not respond correctly causing the request to fail. The HTTP response body might contain a JSON message with further details. For more information about the error, your system administrator can look at the logs. |
503 – Service Unavailable |
IBM Telco Network Cloud Manager - Orchestration is unable to process this request. Do not retry the request until the underlying problem is resolved. The HTTP response body might contain a JSON message with further details. For more information about the error, your system administrator can look at the logs. |
Error responses
- All IBM Telco Network Cloud Manager -
Orchestration API calls return the
following information in the Response Body when an error is encountered, for example, for a 40x, 50x
Response
Code:
{ "details": {}, "localizedMessage": "string", "url": "string" }The Response Body content type is
application/jsonThe response properties are described in the following table.Table 3. Response properties Property Name Description Mandatory detailsAny additional information that is related to the error that might be useful during debugging. Yes localizedMessageThe description of the error that occurs. Yes urlThe URL of the root cause of the problem or null if unknown. No A more fully populated error report from IBM Telco Network Cloud Manager - Orchestration looks like this:{ "url": /api/resource-manager/configuration/923227664489862, "localizedMessage": "A FATAL IBM Telco Network Cloud Manager - Orchestration Driver error has occurred: Unknown Resource Manager 923227664489862", "details": { "responseHttpStatus": 500, "errorStatus": "FATAL", "responseData": { "url": "http://galileo:8283/api/topology/resource-managers/923227664489862";, "localizedMessage": "Unknown Resource Manager 923227664489862", "details": {} } } }More than one set of error details might be included. The error reports show the errors that are generated by components internal to IBM Telco Network Cloud Manager - Orchestration and passed back through the layers of requests that were made.
If a support call becomes necessary, include all the information from any IBM Telco Network Cloud Manager - Orchestration error reports because that greatly helps with tracking the root cause of the problem.
- Rarely, an error might occur within IBM Telco Network Cloud Manager -
Orchestration that for whatever reason cannot be
handled gracefully, and for which an IBM Telco Network Cloud Manager -
Orchestration
error response is not available, for
example:
{ "timestamp": "2017-08-10T15:28:19.586+0000", "status": 500, "error": "Internal Server Error", "exception": "org.springframework.web.client.ResourceAccessException", "message": "I/O error on GET request for \"http://9.20.64.abc:8295/api/resource-manager/configuration\": 9.20.64.abc; nested exception is java.net.UnknownHostException: 9.20.64.abc", "path": "/api/resource-managers" }
The response properties are described in the following table.
| Property Name | Description | Mandatory |
|---|---|---|
timestamp |
The date and time to error occurred. | |
status |
The HTTP status code returned. | |
error |
A textual description of the HTTP status code returned. | |
exception |
The internal Exception type that was raised. | |
message |
The actual error reported. | |
path |
If it was an API call or web service request that failed, then this field identifies what was being requested. |
HTTP status code usage
- 1xx Informational responses
- 2xx Success
- 3xx Redirection
- 4xx Client errors
- 5xx Server errors
1xx status codes are not used explicitly by IBM Telco Network Cloud Manager - Orchestration.
2xx status codes indicate that the client's request was successfully received, understood, and accepted. Different IBM Telco Network Cloud Manager - Orchestration components return different HTTP 2xx status codes dependent on the nature of the request made. To find out which HTTP 2xx status codes are returned, see the individual API help.
3xx status codes are not used explicitly by IBM Telco Network Cloud Manager - Orchestration.
4xx status codes are intended for situations in which the error is caused by the client or user.
A client can also mean another system that is sending a request into IBM Telco Network Cloud Manager -
Orchestration. To understand how the different HTTP
4xx status codes are used, separate the definition of a Service Endpoint from the data that it is
being asked to use. The IBM Telco Network Cloud Manager -
Orchestration definition
of the Service Endpoint is the full path to the Service required excluding any variable
parameters in the URL.
The distinction between the HTTP 4xx and 5xx status codes is intended to make integration easier than if you have one tier of HTTP code. An HTTP 404 status code means that the system cannot find what you are asking for. An HTTP 400 status code means that the service exists but you did not send it the information that it needs or recognizes. For example, you successfully connect with the API end point and send it a request but the request is not understood. Finally, an HTTP 500 status code means that the system understands what you asked it to do, but for some reason it cannot do it.
http://<hostname>:<Port>/api/resource-manager/configuration/9.20.64.abchttp://<hostname>:<Port>/api/resource-manager/configurationAll POST requests send their data in the body of the HTTP request.
All GET and DELETE requests send their data as variable URL parameters.
All PUT requests send their data as variable URL parameters or as data in the body of the HTTP request.
HTTP 400 versus 404 statuses
Within IBM Telco Network Cloud Manager -
Orchestration, the handling of HTTP 400
& 404 status codes varies depending on what type of request that is made. Generally, the 4xx
HTTP status codes are produced by the IBM Telco Network Cloud Manager -
Orchestration functions that are concerned with validating and verifying the incoming requests. This table
summarizes the internal rules that StartOSS uses about when to return an HTTP 400
versus 404 status code:
| Type | URL Invalid | URL (with variables) refers to an Entity that does not exist. | Invalid Body Content | Body refers to an Entity that does not exist. |
|---|---|---|---|---|
| REST | 404 | 404 | 400 | N/A |
| RPC | 404 | N/A. Has no URLs pointing to Entities | 400 | 400 |
- The Service Endpoint that is requested does not exist or is not available (check your hostname and ports).
- The requested resource (as identified by the URL variable parameters) does not exist.
The HTTP 400 status code (Bad Request) is used by the REST-style requests if the POST or PUT contains bad data. For example, if IBM Telco Network Cloud Manager - Orchestration is given a descriptor that it does not recognize or is unable to use.
For RPC-style Requests, an HTTP 400 error is returned if the request body that is sent to the Service Endpoint contains incorrect content. An HTTP 404 error is returned if the requested Service Endpoint does not exist.
HTTP 409 status
The HTTP 409 status code (Conflict) indicates that the request might not be processed because of conflict in the request. Examples include that the requested resource is not in the expected state or the result of processing the request can create a conflict within the resource.
- Data constraint violations
- Concurrent modification exceptions.
HTTP 5xx status
Response status codes that begin with the digit “5” indicate cases in which IBM Telco Network Cloud Manager - Orchestration is unable to do the request or action that is submitted. It indicates that something internally within IBM Telco Network Cloud Manager - Orchestration is preventing the execution of the request. However, the request is syntactically correct and all the mandatory parameters are provided and pass basic validation checks. To put it another way, the API service understands what you ask it to do, you provide it with all the information it needs or expects, but it is unable to do the request.
The most usual case is a simple HTTP 500 status code that is backed up with a JSON payload in the response body. This payload contains a human-readable error message that summarizes the problem and a section that contains further technical details, if available.
API sections
- Assembly Orchestration. IBM Telco Network Cloud Manager - Orchestration enables the creation of Assemblies. Assemblies enable services to be created by IBM Telco Network Cloud Manager - Orchestration which interact with resource managers to create and manage virtual resources that need to be provided for the service to work. This part of the API includes two endpoints. The first enables the External OSS system to request a transition against an assembly instance, including requesting a new assembly instance. The second enables the External OSS to poll IBM Telco Network Cloud Manager - Orchestration to find out the state of the request.
- Asynchronous Events. In response to Assembly Orchestration requests, IBM Telco Network Cloud Manager - Orchestration also puts messages on a Kafka bus. These messages describe the key events that occur during the processing of the request. It also puts a message to indicate when the processing is complete. It is recommended that the External OSS uses this mechanism to check the state of requests rather than using the polling interface defined in the previous section.
- Assembly Topology. The external OSS might need details of the assembly instances and of the components that it is comprised. The assembly topology contains a hierarchy of the components of an assembly. A component might be either a resource or an assembly. It is also possible to request details of the events used during the assembly’s life.
- Resource Manager Handling. Resource Managers are responsible for managing the actual resources that needed for a service to work. IBM Telco Network Cloud Manager - Orchestration needs to be told which resources managers it interface to. This process is known as Onboarding a Resource Manager. The IBM Telco Network Cloud Manager - Orchestration API provides a set of calls that enables a new resource manager instance to be on-boarded to IBM Telco Network Cloud Manager - Orchestration, and also removed from IBM Telco Network Cloud Manager - Orchestration. When a resource manager is on-boarded, the set of resource types and locations that they manage are extracted by using the Resource Manager API. The API also provides an endpoint that makes IBM Telco Network Cloud Manager - Orchestration request the associated resource manager for a set of updated resources. Any existing resources remain unchanged when this update occurs.
Supported media types
application/hal+jsonapplication/octet-streamtext/plainapplication/xmltext/xmlapplication/x-www-form-urlencodedapplication/*+xmlmultipart/form-data**application/json****application/\*+json**
In most cases, by using JSON to supply information as part of an API request is the preferred option.