Publishing overview

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation.
info

Publishing is the process of making your APIs available to app developers for consumption.

Video: The following video provides a high-level introduction to API publishing.

Publishing APIs involves the following tasks, described in this topic:

  1. Create the API products on Edge that bundle your APIs.
  2. Register app developers on Edge.
  3. Register developer apps on Edge.
  4. Provide documentation and community support for your APIs.

Task 1: Create an API product on Edge

The first task in publishing is to create an API product. An API product is a collection of API resources that are offered as a package to app developers for consumption. Create API products by using the Edge management API or UI. (See What is an API product? to learn more about API products.)

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The API icon and resources are highlighted. A dotted line
    points from the developer to an icon of an app the developer has built. Arrows from and
    back to the app show the request and response flow to an API icon, with an app key positioned
    above the request. The API icon and resources are highlighted. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

In this figure, the API consists of two products, each containing three API resources.

As an API provider, you are responsible for building the APIs and API products to handle access control, usage restrictions, and any other business requirements. For example, you might:

  • Release a free API product that allows read-only access to its API resources.
  • Release a second API product for a low price that allows read/write access to the same API resources as the free version but with a low access limit, such as 1000 requests per day.
  • Release a third API product for a higher price that allows read/write access the same API resource but with a high access limit.

The important thing to remember is that Edge give you the flexibility to create API products that match the business requirements of your APIs.

For more information on creating API products, see Create API products.

Task 2: Register an app developer on Edge

A developer creates the apps that consume your APIs. An app developer registers on Apigee Edge before they can register their app. When they register their app, they receive an API key that will give the app access to the API.

Through the app registration process, you control who has access to your APIs. At any time, you can delete an app developer, which invalidates all API keys associated with that developer, therefore denying that developer access to your APIs.

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The developer icon is highlighted. A dotted line points from the
    highlighted developer to an icon of an app the developer has built. Arrows from and
    back to the app show the request and response flow to an API icon, with an app key positioned
    above the request. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

As an API provider, you decide how to register developers. For example, you can use a manual registration process that requires a potential developer to contact your organization to register. The potential developer must supply all necessary information, such as an email address, first and last name, and company name. If you approve the developer’s request, you can use the Edge management UI to manually register the developer. See Managing app developers for more.

Apigee also provides tools that you can use to automate the developer registration process. For example:

  • Use the Apigee Edge management API to integrate registration functionality into your existing website. The Edge management API is a REST API that you can use to perform all aspects of the developer registration process. See Using the Edge management API to Publish APIs for more.
  • Use the Apigee Developer Services portal to register developers. The portal has built-in support for developer registration, but also has many other features to support your APIs. See What is a developer portal? for more.

Task 3: Register a developer app on Edge

Before an app can access your APIs, the app must be registered on Edge. However, only a registered developer can register an app on Edge.

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The app, request/response, and API key arrows are highlighted. A dotted
    line points from the developer to an icon of an app the developer has built. Arrows from and
    back to the app show the request and response flow to an API icon, with an app key positioned
    above the request. The API icon and resources are highlighted. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

At the time of app registration, the developer selects one or more API products. For example, you might publish multiple API products corresponding to different types of services and pricing plans. The app developer can then pick and choose from the list of available API products.

In response to registering the app on Edge, Edge assigns a unique API key to the app. The app must pass that API key as part of every request to an API resource. The key is authenticated and, if valid, the request is granted. At any time, you as the service provider can revoke the key so that the app can no longer access your APIs.

As an API provider, you decide how you want to register apps. You could:

  • Use a manual process that requires a developer to contact your organization to register their app. In response, you would send the developer the API key, possibly by email.
  • Use the Edge management API to integrate app registration functionality and key delivery into your website.
  • For a paid Edge account, use the Apigee Developer Services portal which has built in support for app registration and API key delivery.

For more information, see Register apps and manage API keys.

Task 4: Document your APIs

An important consideration for publishing API products is providing documentation and a developer feedback mechanism. Developer portals with social publishing features are increasingly being used for communication with the development community. This includes communicating static content, such as API documentation and terms-of-use, as well as dynamic community-contributed content such as blogs and forums, as well as customer support features.

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The developer icon is highlighted. Below the developer is a box that
    represents a developer portal. The portal contains API documentation, samples, tutorials,
    API reference, and other. The portal also contains blogs, forums, and a support portal.
    A dotted line points from the highlighted developer to an icon of an app the developer has
    built. Arrows from and back to the app show the request and response flow to an API icon,
    with an app key positioned above the request. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

You can build your own website to deploy your documentation or, if you have a paid Edge account, you can use the Apigee Developer Services portal. The portal has built-in support for documentation, blogs, forums, and other types of content required to support your developer community.

SmartDocs lets you document your APIs on the Developer Services portal in a way that makes the API documentation fully interactive. Interactive documentation with SmartDocs means portal users can:

  • Read about the API
  • Send a live request to the API
  • View a live response returned from the API

For example, the following figure shows an API documented on the portal by using SmartDocs. This API provides weather information for a specific location:

A SmartDocs API method topic that lets you call a weather API by clicking a button
    in the topic.

The developer enters a value for the 'w' query parameter to specify the location, and then clicks the Send the request button to see the live request and response. By creating an interactive documentation on your APIs, you make it easy for portal user to learn, test, and evaluate your APIs.

The Edge management API is a REST API that enables you to access API Services using any HTTP client. Apigee uses SmartDocs to create interactive documentation for the Edge management API. See that API documentation here.

For more information, see Using SmartDocs to document APIs.