InfoQ Homepage API Content on InfoQ
-
InfoQ Call for Articles
InfoQ provides software engineers with the opportunity to share experiences gained using innovator and early adopter stage techniques and technologies with the wider industry. We are always on the lookout for quality articles and we encourage practitioners and domain experts to submit feature-length (2,000 to 3,000 word) papers that are timely, educational and practical.
-
An "Integration-First" Approach to Building a Commerce Platform for Payment Terminals
In this article Praveen Alavilli describes how they designed a payment terminal system for interoperability and extensibility, allowing developers to build new shopping experiences.
-
Key Steps to Building and Managing an Effective API Marketplace
Across industries, companies are now looking for ways to shape their digital businesses by extending their services through external APIs. To reap the benefits of an API program, however, organizations need to move beyond basic API management to creating an API marketplace, a specialized type of platform business model that focuses on connecting producers and consumers.
-
Always Be Publishing: Continuous Integration & Collaboration in Code Repositories for REST API Docs
API documentation is an often overlooked part of making any API a success. This article explores how to make the documentation part of a continuous integration pipeline keeping it closer to the code itself.
-
Untangling an API-First Transformation at Scale. Lessons Learnt at PayPal – Part 3
This is the third in a three-part series that explores how PayPal has adopted a more API-first approach to building platform services. In this article, we’ll take a closer look at the program aspects and some of the execution and operational challenges that had to be overcome.
-
Untangling an API-first Transformation at Scale. Lessons Learnt at PayPal – Part 2
This is the second in a three-part series that explores how PayPal has adopted a more API-first approach to building platform services. In this article, we’ll take a closer look at how the portfolio of API’s themselves are managed.
-
Untangling an API-First Transformation at Scale. Lessons Learnt at PayPal – Part 1
In the first of three articles, Erik Hogan describes how PayPal went from a monolithic, siloed architecture to a much more loosely coupled set of over 150 services with well designed, modern APIs over the course of three years.
-
How Zalando Delivers APIs with Radical Agility
InfoQ interviewed Thomas Fraustein, architect at Zalando, about his team’s radical agility development organization that is optimized for an API-first approach. He explains what an API-first approach is, and provides tips on building good APIs for scalable microservice architectures where a large number of services are offered efficiently.
-
Virtual Panel: Document and Description Formats for Web APIs
In this virtual panel we hear from 4 individuals deeply involved in the Web API space. Each of them has a unique take on the values, benefits, and costs of documentation and description formats in general, and provide their own unique perspective from their vantage points across the Web. They agree on one thing: something must be done to help developers find their way through the world of Web APIs
-
An Open API Initiative Update
The Open API Initiative group is evolving what has become the de-facto standard API Description Format to produce a consistent and compatible format for describing APIs, allowing interoperation between tooling, systems, and runtime environments. Tony Tam, creator of the popular Swagger Specification is providing an update on the group activity.
-
On Abstractions and For-Each Performance in C#
Donald Knuth famously said, “We should forget about small efficiencies, say about 97% of the time”. But when faced with the other 3%, it is good to know what’s going on behind the scenes. So in this article we’ll be taking a dive into the foreach loop.
-
Designing with Exceptions in .NET
Exceptions are an integral part of working with .NET, but far too many developers don’t think about them from an API design perspective. Most of their work begins and ends with knowing which exceptions they need to catch and which should be allowed to hit the global logger. You can significantly reduce the time it takes to correct bugs if you design the API to use exceptions correctly.