Sustainable API
Sustainable API are Robust API that can be recombined or reused for a given foreseeable future. Its about embracing device diversity.
Life-cycle Management
API’s are the way your customers will interact with your business, it’s important to treat API similar to that of an customer facing initiative. Planning and managing their development life-cycle, while clearly communicating the expected support and availability time frames. Customers are unlikely to launch into the development of new application that Consumes your API, if the API is likely to change to frequently. At the same time, emerging security, identity and standards, require certain updates to keep current. A great example is Twitter retiring API 1.0 in favour of API 1.1 forced to extended the retirement date 3 months, yet still received heavy criticism from their developer community. Maintaining multiple versions and supporting the last 2 or 3 versions much like software is essential to give those further along the value chain time to redevelop their Consumer nodes.
Selecting well supported and defined industry stands to ensured both the broadest coverage and the ability, to automate the conversion or format of the API as new standards emerge. Developing the sustainable API requires stricter documentation and standards adherence. Strict standards adherence enables device and delivery mechanism (Saas, Cloud, Mobile etc) independence.
The most common concern I have heard about Open API or Open Government is the lack of predicable stability. Predictable Stability reduces the value of the API data sets. Client applications may now or in the future require SLA’s (Services Level Agreement) to offer their customers in turn. Up-time, response time, security, redundancy and disaster recovery are key to acceptance and adoption API. Small changes in response formats, can create a huge amount of manual effort. Injecting a new field, or missing one response, can break the chain and cause data corruption for multiple Clients. Testing under distributed load, and tracking production traffic in order to keep abreast of performance and network bottlenecks is highly recommended.
It is good practice to do regression testing when developing any application or API. Regression testing between instances in development, pre-production and production. With API’s and API Client relationships are less formal, running a regression test on production to identify any changes that may otherwise go missed is essential. Tools like SOAPSonar allow for baselining and scheduled regression testing, automating the comparison of results to previous test cases.
Componentized
Another key aspect of Sustainable API is keeping them as smaller building blocks. Much like Lego, Providing smaller componentized API allows Clients to consume only the information they need. Particularly important if these API get extended over mobile or poor quality networks.
Early adopters of SOA, tended to develop Wide API. API that responded with 100’s of fields, like the entire customer record. This drove up CPU and Network utilization if a query only required the customers 5 address fields. Mobile Networks, and lower CPU powered mobile devices and the Data Economy has shifted the focus to reusable or stackable component based API that are requested concurrently or sequentially as needed. This increases performance, reduces server and network loads and better supports a wider variety of possible future applications. Componentizing API increases the number of API, but reduces the need to create overlapping API and versions.
When a new B2B or other partner requires access to only partial subset of an API, organizations are left needing to do one of 3 things
- Create a new API for the new partner
- Exposing unused components for Consumption by the partner who then discards the parts not required,
- Mediating, stripping out the unwanted or private fields in the API using filters or a message body parsing device like an API gateway to convert the message body and create a new virtual API with only the required fields.
Another benefit Componetized API is development, QA and life-cycle management. Complex Wide API with many lines of code cost considerably more to develop, troubleshoot, test and adapt. Hidden quality issues often land up becoming Common Law Features, as the bugs exist for so long and effects so many systems that user support is needed if it was ever to be fixed.
With the rapid development and definition of new IoT, Cloud, Saas, Identity and message formats to support the Data Economy, more and applications organizations are redeveloping their SOAP based services into REST, using OAuth or SAML based identity. Redeveloping the same data sets on new endpoints in order to support these new standards. Buy componentized, Identity or other parts can be altered or changed without a full redevelopment.
Conclusion
In the Data Economy, Nodes may Consume information from multiple sources, refine it or apply some logic to the information then Provide the result in turn for other Clients to consume. As the Data economy matures, I expect that these value chains will grow in length, number and complexity. Sustainable API are those that have the flexibility and staying power to define and maintain their place in these emerging value chains.