API Digest #67: 4 Important Takeaways from the Changing API Ecosystem
Hello to all API enthusiasts! Here we are with a fresh portion of API related news In this issue you will read about:
- 4 Important Takeaways from the Changing API Ecosystem
- 4 Design Tweaks to Improve API Operations
- API Design: Think First, Code Later
- Considering Standards In Our API Design Over Being A Special Snowflake
- SXSW 2017: Make APIs as Easy to Use as the Web - The New Stack
- A Visual Guide to What's New in Swagger 3.0
There has been a lot of changes amongst companies that provide API-related solutions. The most noteworthy example is Google's $625 million acquisition of API platform provider, Apigee, in the fall of 2016. Keshav Vasudevan points out four primary takeaways from the changing API ecosystem software teams should be considering. He explains what this momentum means for API providers, and how they should respond as these developments continue to unfold.
Over the past few years, Swagger 2 has become the de facto standard for defining or documenting your API. Since then, it's been moved to the Linux foundation and renamed to OpenAPI Spec. Version 3 has been in the works for a while, and it's finally feature complete! Here's a visual guide by Gregory Koberger to what's changed, and how to upgrade from Swagger 2 to OpenAPI 3.
Many API owners overlook many operational consequences while designing their APIs. For example, it can be that URLs are designed without metadata to describe actions, later on, product owners will have a difficult time staring at unintelligible logs. Or, if microservices aren’t orchestrated correctly, there is the risk of long load times queuing multiple API calls in a mobile environment. Bill Doerrfeld shares 4 Design Tweaks to Improve API Operations and how to make APIs more responsive to the way that clients will consume them.
As a software developer, Jonatas Baldin knows how hard it is to contain the urge to start coding as soon as we can. Despite how great we feel while developing, it’s always a good idea to take a step back and see the bigger picture. When it comes to API Design, Jonatas Baldin recommend you to think first, code later.
Most of the APIs Kin Lane encounters are special snowflakes. The definition and designs employed are usually custom-crafted without thinking other existing APIs, or standards that already in place. So, whenever he finds an API that is employing an existing standard, he feels compelled to showcase and help plant the seeds in others minds that we should be speaking a common language (Considering Standards In Our API Design) instead of always being a special snowflake.
Up until recently APIs have been part of the tech domain almost exclusively. As they go mainstream, it's becoming more and more evident that creating, launching and supporting an API is a highly iterative process between technology and business. by Inés Luna writes about how to calculate the overall cost of an API, and its lifetime value. She suggests measuring growth for your API using the SaaS analogy.
Externally exposed APIs should be just as easy to use, and work just as seamlessly as the Web, so argues API expert Mike Amundsen. He gave a talk on "evolving the API” at the SXSW Interactive. He tells about A lingua franca for services and APIs, how would these evolving APIs look to developers, over time, a DNS for APIs and more.
See you in a fortnight! In the meanwhile, send us article suggestions and ideas. Either way, we are happy to hear from you. :)
P.S. In case you’d be interested in trying API2Cart, you can create an account and see how the API works on live stores.