Development Lifecycle of an API

Software API development lifecycle

Every software company or startup has a unique software development lifecycle that they are using. It is often necessary to synchronize and align RESTful API deployment with the same processes that you use today for developing, testing, and deploying other applications.

Some services provide tools and sometimes even RESTful APIs that enable you to integrate their tools into your own development lifecycle. A common usage of the RESTful API is to write scripts or code that programmatically deploy REST API web services, or that migrate REST API services from one environment to another, as part of a larger automated process that also deploys or migrates other applications.

For example, RestCase is an online cloud software that makes no assumptions about your software development lifecycle or process (or anyone else's, for that matter). Rather, it exposes atomic functions that can be coordinated by your development team to automate and optimize your REST API development lifecycle.

API Development Lifecycle

RESTful design increases API performance, reduces development effort, and minimizes operational support burden. By conforming web applications, web services, and web APIs with proven RESTful constraints, teams can create systems as scalable, pervasive, and prolific as The Web itself. Because REST requires a new development mindset, many API implementations are not truly based on REST constraints and principles, and do not exhibit expected scalability, evolvability, and interoperability.

By following a few best practices and selecting RESTful tooling, teams can easily design, evolve, and connect RESTful APIs. Some of the best practices evolves handling REST API error codes properly.

I will try to show the REST API development lifecycle that is used more commonly through the companies I am familiar with.

  • REST API or API Service is used to represent the whole set of Resources and functionality designed as a single deployable unit, for a specific version of the API.
  • The purpose of the API Lifecycle is to create a common frame of reference around the main stages, or milestones, of the life of an API Service.
  • From a governance standpoint, we recognize that there is a process that moves an API Service from one stage to another, and that process is called a transition.
  • It is commonly accepted that ~80% of the risks associated with managing IT systems are concentrated during those transitions.
  • As a governance group, one will therefore focus attention on the processes that we may want to implement before the start of a transition, and after it ends.
Common REST API Service Development Lifecycle:

Common API Service Development Lifecycle

  1. Proposed
    Reflects the state of a new API or the new (next) version of an API being proposed. A new proposed API is presented to the API Governance Board where it is evaluated from a product and technical perspective. The board will either be reject or approve the proposed API.

  2. Accepted
    Is the state of an API when it was reviewed by the API Governance Board and approved to move further.

  3. Designed
    The API goes to design and its specs are fleshed out in a specifications document. Once designed, the API will then be presented to the architecture review for final approval.

  4. Approved
    Once it passes the architecture design review, the API service is approved, and authorized for production release.

  5. Released
    The API Service is live in Production.

  6. Cancelled
    API are cancelled either by the API Governance Board or by the author(s) depending on the life cycle stage when the decision is made.

  7. Deprecated
    An API is deprecated when it is no longer supported, either because a newer version has been deployed or because the product is no longer part of the company portfolio.

  8. Retired
    A retired API is no longer deployed in the production environment and is no longer in use.

The most import is to Design an Easy to Use API

API design does not equal service design. In addition to designing the interface message (REST representation), carefully craft URL identifiers (REST resources), define usage policy (i.e. rate limits), and
service level agreement (i.e. response time, availability). Take a resource identifier first focus and allow flexible representations. Allow clients to negotiate the representation format, and RESTful clients will permissively process the representation. An example of permissive processing is a Web browser that will render malformed HTML rather than displaying a blank page. Design resource identifiers for faster interaction by conforming design to uniform interface and HATEOAS conventions.

API - the Lifecycle

APIs must be treated as products to maximize their successful uptake

  • Consistency across operations and APIs
  • Naming, usage patterns
  • Documentation
  • SDKs
  • Live sandbox environments for app onboarding
  • etc.

How can enterprises achieve the necessary level of quality and consistency for their APIs?

  • “Just enough governance” – define the content, rules and roles required to produce and expose enterprise-quality APIs
  • Automate what you can
  • Review what you can’t automate
Manage APIs like products and developers like customers

APIs and developers each follow a lifecycle with stages of maturity that require proper management. APIs need to be managed like products and developers need to be managed like customers. The right API management solution enables organizations to manage both lifecycles independently and successfully.

API Lifecycle management enables API owners to:

  • Align API programs with business objectives, simplify API creation and publishing, manage and govern changes to meet internal policies and regulatory requirements, control and communicate updates, monitor availability and measure performance.
  • Enables developers to discover new and updated APIs, register for access to APIs, leverage development tools, test client apps and collaborate with other developers.
Conclusion

In today's world, Restful APIs are becoming more & more popular. Although many companies still work non-efficiently when it comes to developing new REST API services. I think that embracing tools that gives the company a high level overview and control for the development of REST APIs can save time, give a huge boost in the eyes of the customers \ developers and increase the quality of the services offered.

Guy Levin

Read more posts by this author.

comments powered by Disqus

Subscribe to REST API and Beyond

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!