Publish an API, configure license scope to determine what licenses will be offered for the API, and perform maintenance activities.
APIs are business capabilities exposed over the internet for applications to use. Simply put, an API is a programming interface that your organization exposes over the internet that allows applications to communicate with your backend systems. Typically, you build APIs that expose specific aspects of business functionality. These are things that differentiate you in the market place and that make money for you and your company. So essentially what you are doing through the creation of APIs is creating a new channel for your business by exposing a set of capabilities for your product (i.e., services that people can build into mobile applications and sell to their customers), thereby creating a channel for your products and services online.
The platform supports public and private APIs. Public APIs are visible to members (users who have signed up and logged in) and visitors (users who have not yet signed up). Private APIs are visible only to platform users who are members of one or more groups that have been specifically invited to have visibility of the API.
In the platform, any API or other resource that is private is shown with a "lock" icon to indicate privacy.
Developing an API includes these key phases: Plan, Build, Run, and Promote.
Planning:
The planning phase involves determining which APIs to publish. Key considerations when selecting APIs include:
Build:
After the API has been planned, approved and appropriately scoped, the next step is to build it. Jet considerations when building an API:
Building an API that is simple, easy to understand, and well documented will encourage developers to use it.
Run:
After the API is built, the next step is to run it. Key considerations when running an API include:
The API must be robust and managed. To achieve this you must provide developers with feedback that the API will perform reliably in terms of functionality, performance, and its ability to security the customer data.
Promote:
Once the API is running you must promote it. Key considerations when promoting an API include:
Collaborate—To market your API to a set of consumers (i.e., developers writing applications) you must create a community around your API. Creating a community of partners provides a value add to your services and your APIs and allows developers to collaborate with each other. This can be accomplished in the platform using the API Group and API Board functions.
Search—Users need to be able to effectively find your APIs, you need to get access to the documentation and collaborate around developing their applications. This can be accomplished in the platform using the Search function where users can perform a free text search or use a pre-defined search filter.
Support—You must support the API effectively. As you write your APIs you may run into problems and would like gain expertise and advice from community members. This can be accomplished in the platform using the API Board, trouble ticket management system, and by submitting a support request.
The minimum requirement to add an API to the platform is that it must have an endpoint. For example:
The platform allows you to secure and monitor your APIs with the following pre-configured policies. These policies are selected by default and should be assigned to newly created APIs. Three policy categories are supported:
Policy Name | Description |
---|---|
ApplicationSecurityUnsigned | This is a default security policy for platform applications. Policy Category: Simple Header Security |
ApplicationSecuritySigned | This is a default security policy for Enterprise API Platform applications. It provides support for SHA1 (Shared Secret). Policy Category: Simple Header Security |
BasicAuditing | Provides basic auditing of messages. Message metrics will be recorded in the Usage Logs Monitoring tab. The messages themselves will not be audited. That can be achieved using the DetailedAuditing policy. Policy Category: Monitoring |
DetailedAuditing | Provides detailed auditing of messages. Message metrics will be recorded in the Usage Logs Monitoring tab as well as the entire messages of each exchange. Policy Category: Monitoring Policy Type: WS-Auditing Service Policy Configuration: Audit All Messages, Audit Input Message, Audit Output Message, Audit Fault Message, Audit Message Size, Audit Binding, Audit Transport, Audit Contract, Audit Identities (Consumer and End User), Reporting Options (Log) |
OAuthSecurity | The OAuthSecurity Policy uses the OAuth configuration assigned to an API when enforcing OAuth tokens in the received request. Note: Selection of this policy is typically assigned to an API after performing the Edit OAuth Details configuration on the API Details page in the Community Manager portal. Use Edit on the API Details page, go to the 3. Proxy page, and in the Advanced Options select OAuthSecurity in the Policy section. Policy Category: OAuth Policy Type: XML Policy Configuration: Do not configure. |
If you subscribe to an API Enterprise Management Platform or decide to install on-premises then you also have the ability to create and manage your own Policies. If you require a policy that is not on the default list, submit a support request..
When you add an API using the Add a New API Wizard, in the Policies section on the Proxy page, you MUST select one security policy (e.g., Category: Simple Header Security) and you should select a monitoring policy if you want to see charts and logs. If no policies display, consult your API Provider or Site Administrator.
Your ability to add an API, and the choices available to you, vary according to the configuration settings for the specific instance of the platform you are using.
If you have the applicable permission, you can add an API. Click the Plus Menu (the + icon at the top of the page) and choose Add a New API. For additional instructions, see How do I add a new API (API with New Service)? below.
In some cases, your version of the platform might be configured to allow you to either add an API by defining a new service, (SOAP-based or REST-based), or add an API for a service that's already defined in the API Gateway.
If this is your scenario—from the Plus Menu (the + icon at the top of the page), select Add a New API and you will see the Select Type of API overlay. Choose one of the following:
Note: If the above options are not available to you and you feel they should be, contact your Site Admin for assistance.
The platform provides an Add a New API function that allows you to add a SOAP or REST-based API. APIs can be added for both Sandbox and Production environments.
Note: If you want to add an API from a service already defined in the API Gateway, use the Add API from Service option (if available) instead of Add a New API. For more information, see How do I add an API from an existing API Gateway service (API with Existing Service)? below.
Prerequisites:
The Add APIs Wizard includes the following sections:
API
On the API page you perform the initial step of specifying an API Name, Version ID, Tags, Visibility (Public/Private), API Description, Version Description, and API Icon. This information displays on your public API page which also displays in the API search results.
A platform user who performs a search and finds your public API page, sees the API description and can rate and write and review your API. Individuals can also participate in a Yes/No survey indicating whether a review was useful or not. Based on this high visibility it's important that your API description is highly informative and includes the necessary marketing, functional, and use case information that will engage customers to request access to your API.
Target
On the Target page, you can configure SOAP-based APIs by specifying the SOAP version and WSDL. REST-based APIs are configured by specifying one or more operations. Policy selection is not required for the Target URL.
Proxy
The Proxy API page allows you to configure your API's proxy settings. If you would like to proxy your API, select the Yes radio button in the Proxy API section. There are many benefits to proxying your API including utilizing platform security and service-level policies, monitoring performance, and allowing App Developers to gain access to your API sandbox endpoint (to test API functionality in their app), and production endpoint (to use API functionality in a live application). The Allow Anonymous Access option allows you to enable anonymous access to an API endpoint if you would like to offer a preview of an API to developers without requiring users to create an app or sign up to the platform. For more information, see What is anonymous API access?
A. Launch the Add a New API Wizard
Note: In some implementations, only a Business Administrator can add an API. If the option to add an API is not available to you and you feel it should be, contact your Administrator.
B. Specify API General Information
C. Specify Target URL and Environment
D. Configure Advanced Options
By default, the REST protocol is selected for your API, a Default Profile (Any in and out), and Default Operation are specified. After specifying the Target URL and Environment, you can optionally update the existing protocol (REST), or change the protocol to SOAP in the Advanced Options section.
Configure Protocol:
Operation | Method | URI | Request (Input) | Response (Output) |
---|---|---|---|---|
list | GET | / | N/A | text/xml |
read | GET | /{id} | N/A | text/xml |
add | POST | / | text/xml | text/xml |
delete | DELETE | /{id} | N/A | text/xml |
update | PUT | /{id} | text/xml | text/xml |
E. Configure Proxy
F. Enable / Disable Proxy API
G. Configure Production Endpoint
H. Configure Advanced Options
If you already have an API that's set up as a service in the API Gateway, or you want to create the service using the flexible service definition model offered by the API Gateway, you can use the Add API with Existing Service function to add the API to the platform.
The platform references the information already set up in the API Gateway so you don't have to set up all the API details again.
You might choose this option over the "Add API with New Service" option if your service matches any of the following descriptions:
If your API is using the Licenses feature, scope mapping is the key to defining which portions of your API will be available for which licenses. The scopes and licenses themselves are defined by the Business Admin, but at the API level you determine which operations are assigned to which scopes. This in turn determines which licenses will be available to app developers requesting access to your API.
For example, let's say your API includes a set of operations relating to calendar functionality and another set of operations relating to email access and management. App A might only need access to the calendar functionality, and App B might include an email client and might require access to the operations relating to email. The scope mapping feature enables you to group individual operations into logical groups that can be separately packaged into a license for App A and another for App B.
As another example, let's say you want to offer access to your GET operations, and a higher level of access, for a fee, to all operations including add, modify, and delete. The Business Admin defines READ and MODIFY scopes, and then assigns each to a separate license. The API Admin assigns GET operations to the READ scope and assigns all operations to the MODIFY scope. Users who choose the paid license get access to all scopes; users who choose the free license can only access the GET operations.
At runtime, when a request is received to an API proxy from a particular app, the request is only passed through to the API if it is using one of the specific operations covered by the license governing the app/API contract.
As a standard practice, a list of available Licenses and the level of App Access provided by each License should be included in the documentation for your API.
The following example illustrates how to add a REST service from the BingVirtualEarth API.
Pre-conditions
A. Add REST Service
B. Set up Contract
C. Test API
You can test the API with the Dev Console or with the REST clients mentioned in the Pre-conditions section above.
The request URL should be the added API URL with the same parameters for the physical service. For example:
http://<API_URL>/<API_path>?postalCode=90020&o=xml&key=AoCDRhKKY0Gy6hlx1Ncl1PwiV7GqoGU_MebxLQvmhxy_bsAtzVfmVtzFsjOYSCTZ
When you create an API using the Create a New API function you can control whether visibility of the API is Public or Private via the "Visibility" option. You can change API visibility based on your requirements by using the Edit function on the API Details page.
The Add a New API function includes a proxy API option that allows you to configure an endpoint in a particular environment (e.g., internal or external network) that is accessible by your target applications.
A proxy API endpoint exists in the Cloud and is similar to a virtual service. As a security measure, users will be able to access a proxy that will run in the Cloud, and will not be accessing the API implementation directly.
Based on the development cycle of your API, you can chose to expose selected functionality in your API by defining a Proxy API for each endpoint and selecting which functionality (e.g., operations) you would like to expose. This approach allows you to manage the API lifecycle and expose functionality based on your requirements (e.g., development phase, testing, production, etc.).
Advantages:
Internal / External Networks—If you would like to access to your real API on an internal network, but would like to expose specific functionality on an external network, you can add the API Target URL using the Add a New API function, and then virtualize the API by specifying a Proxy API Target URL for specific functionality you would like to make available on an external network.
Bridge Between App and Proxy API—If your API is focused on the business aspects of the API or service, you can set up the proxy API to provide other tasks such as security enforcement or specifications required by the target (e.g., API specs for the app team, etc.).
Sandbox / Production Endpoint Access—Adding a Proxy API allows app developers to gain access to your API sandbox endpoint (to test API functionality in their app), and production endpoint (to use API functionality in a live application).
Contract Enforcement—If you configure your API with a proxy, you can take advantage of the platform's contract enforcement functionality. Here's how it works:
Service-Level Policies —If you configure your API with a proxy, you can take advantage of the service level and quota management policy functionality to monitor your API to ensure it meets the defined standards of service level performance contracts.
Example Scenarios:
Scenario 1—You build an API and would like to expose specific functionality for the purposes of collaborating with a selected development and/or discussion group. You do not want to the API to be visible to anyone outside the selected group. To accomplish this:
Scenario 2—You build an API and would like to expose specific functionality to the public for them to use in their applications. To accomplish this:
An "API Type Profile" is used for proxy APIs to identify the type of content an API will accept from the consumer (IN), and will be returned by the API to the consumer (OUT). IN and OUT identifiers are combined with content types (i.e., ANY, JSON, FORM, and XML) and are packaged on the API Type Profile drop-down menu in profile sets. The following content types are supported:
Content Type | Description |
---|---|
ANY | Indicates that the content is not part of the API definition. Refer to the API documentation for an explanation. |
JSON | Indicates that JSON will be expected. Refer to the JSON specification for more information (http://www.w3.org/TR/rdf-sparql-json-res/#mediaType). |
FORM | Indicates that form encoding will be expected. Refer to the form- urlencoded Media Type specification for more information (http://www.w3.org/MarkUp/html-spec/html-spec_8.html). |
XML | Indicates that XML will be expected. Refer to the XML specification for more information (http://www.w3.org/TR/REC-xml/). |
If you chose to proxy your API, you can optionally configure the operations with Methods, URLs, and Content Types. After the API settings are saved, the specified information is synched with the Target URLs. The following options are supported:
Option Name | Description |
---|---|
Method | The "Method" is a dropdown menu that allows you to map to the HTTP method that must be used at runtime when formulating an HTTP request message. Options include ANY, GET, PUT, POST, and DELETE. |
Path | The "Path" is a text field that allows you to specify a location attribute that can be used to map portions of an HTTP request URI to portions of a WSDL input message. The specified syntax must match the inbound URI pattern. For example, if the HTTP URL looks similar to http://endpoint/context/quotes/xyz where xyz is a variable, then the URI syntax would be /quotes/{var}. The URI can contain multiple variables denoted by {}. This field is optional. |
Content Types | The Request and Response sections (accessible by clicking Show for each operation), includes a list of "Pre-defined" content types that support different message processing requirements for Input and Output messages. Request Content-Type—This option is used to describe the content type of the Request Message. The platform uses input serialization to correctly set the content type of the request being issued. The "Pre-defined" content types include API Default, Any, application/x-www-form-urlencoded, text/xml, application/xml, and application/json. 1) If the request message is a GET or DELETE, the query string contains items that are appended to the resulting XML or JSON message. 2) If the request message is a PUT or POST, the body contains a URL encoded string whose elements are appended to the resulting XML or JSON message. A value of an XML-based content type assumes that the body contains the whole XML message. Response Content-Type—This option is used to describe the content type of the response message when it is not a fault. The platform uses output serialization to correctly set the content type of the response sent back to the consumer when the response is not a fault. The "Pre-defined" content types include API Default, Any, text/xml, application/xml, application/json. NOTE: If Proxy API = Yes, the selected content types are automatically synched to the specified proxy address. If you do not want the content type selections synched to the proxy address, click delete next to the "sync to proxy" icon. |
The Add API Wizard includes an Allow Anonymous Access option on the Proxy page that allows you to enable or disable anonymous access to Sandbox and Production endpoints.
Allowing anonymous access to an API endpoint in the Sandbox environment is useful if you would like to offer a preview of an API to developers without requiring users to create an app or sign up to the platform. For example, if you have a specific feature set you would like to expose as part of promoting your API, you can expose those operations in your API configuration, and enable the Proxy API and the Allow Anonymous Access option.
Developers can read the documentation and access the API without signing up and requesting access to the API. If a developer tries out the API and likes it, he/she can then sign up to the platform, create an app using the Add a New App function, and submit an API Access Request.
Note: Anonymous access is typically granted to API Sandbox endpoints, but it is generally not a standard practice to grant anonymous access to Production endpoints.
When you enable anonymous access in the Add a New API Wizard by selecting Yes to Allow Anonymous Access on the Proxy page, the This API Requires Approval option is disabled. This means that app developers are not required to submit an API Access Request to access the API, except in the following scenarios:
API Charts / Logs with Anonymous API Access:
When you add a new API, the "Version ID" that you specify in the Add a New API Wizard represents the version number that will display on the Version drop-down menu. You add a new API version using the +Version function on the API Details page. Adding an API version follows the exact same process as adding your first API except that the information from the current API version is replicated. From here you can edit/customize the API definition based on your requirements.
The platform includes two options for adding an API, accessed via the Add a New API function on the Plus Menu (the + icon at the top of the page); Add a New API and Add API with Service. The steps for editing an existing API vary according to the way the API was originally created.
You can modify your API definition using the Edit function on the API Details page.
You can export information about an API to an external file. You can then import that file to another instance of the platform. One use of this feature is to move data from one environment to another, such as from a development environment to a testing or production environment.
You can also choose whether or not to export additional data associated with the API, such as policies, contracts, scopes, and documentation.
The API export file includes all the core information about the API, as well as any of the optional additional information you specified.
The file has a very specific structure. It will look something like the image below:
The export file will generally include the following:
Once you've exported an API to an external zip file, it can be imported to another environment. For example, you can export from a development environment and then import to a testing or production environment.
The Business Admin can export information about an API to an external file. However, only a Site Admin or Business Admin can import.
If you need help with import functions, contact your Administrator.
If you are an Administrator, refer to How do I import site, app, or API information from an export file? for instructions.
There are a couple of steps you'll need to complete in your API setup to define the licenses that app developers will see when requesting access to your API:
The scopes are the link between your API and the licenses that are offered to app developers. If you have any questions regarding which scopes to assign or which licenses will be available, consult your Business Admin.
For an overview of the Licenses feature and the relationship between the setup steps performed by the Business Admin and those done by the API Admin, and the relationship between scopes and licenses, see Licenses: Feature Overview.
An API Administrator can change the license for a specific API Access Request prior to approving the request.
If you want to review the license scope of API access requests before approving, make sure you've selected the This API requires approval option in the API setup (API > Edit > Proxy page). If the API is set to auto-approve requests, you won't have the opportunity to modify the license.
You can review the status of your API's connections, including pending and active API access requests, in the My APIs > API > Apps page. This page provides a high level summary of workflow status for apps with current API access contracts or pending API access requests for the current API.
Each listing includes:
The following table shows App Status and App Management Tasks for app/API contracts:
Contract Status | Description |
---|---|
Access Requested | An App has requested access to an API but the request has not been approved and activated in the Sandbox or Production environment. |
Active | API Access has been approved and activated. |
Inactive | API access has not yet been requested. |
Rejected | The API Access Request has been rejected. |
Suspended | API Access that was previously active has been suspended. |
App Management Task | Description |
---|---|
Cancel | Cancels an API Access Request. Listing is removed from the API Connections page. Requestor must submit another request to initiate the process again. |
Suspend | Suspends the API Access Request. This action can only be performed when the request status is Active. |
Resume | Resumes the API Access Request and changes the request status to Active after it has been suspended. |
Switch to Sandbox | Switches the app to the Sandbox Environment and uses the Sandbox Endpoint. |
Switch to Production | Switches the app to the Production Environment and uses the Production Endpoint. |
API Access Request Task | Description |
---|---|
Approve | Approves the API Action Request. Note that the request still requires activation after it has been approved. |
Reject | Rejects the API Action Request. |
Cancel | Cancels the API Action Request. Requestor must submit another request to initiate the process again. |
Activate | Activates the API Access Request. |
Suspend | Suspends the API Access Request and is performed after the request has been activated. |
Resume | Resumes the API Access Request and puts it into an activated state after it has been suspended. |