In the literature, you’ll easily find information on how to rate-limit your API. I even talked about Web API rate limitation years ago at a conference, covering the usage of HTTP headers like X-RateLimit-*. Rate limiting is important to help your service cope with too much load, or also to implement a tiered pricing scheme (the more you pay, the more requests you’re allowed to make in a certain amount of time). Read more...

What are the activities of the Web API developer? How API tooling should not get in the way of developer’s productivity? I presented a talk on this topic at the GlueCon conference: The API ecosystem provides powerful tools, online services and definition formats for designing, testing, running, or managing APIs. All share common purposes: improve our productivity when developing an API, allow us to collaborate more effectively, or share our creations with the world! Read more...

At GlueCon, I presented about the 5-sided prism that polarizes Web API development: How do you tackle your API development? Are you diving head-first in the code to get something quickly out the door? Do you start by defining the API contract, that you’ll share between your teams and the consumers? Perhaps you prefer to describe your acceptance tests, explaining the behavior you expect from your API. But if you’re a storyteller, you’ll probably write some use cases, scenarios, to have a better feel for what your API is all about, and how your users will take advantage of it. Read more...

At our disposal, we have so many ways to interact with an API: from a mobile on iOS or Android, from a web application, or from other services or microservices. And all of them have different needs: one wants only a shallow overview of the data, while the other desires a detailed view of a certain resource and all its sub-resources. It’s becoming difficult to design an API that caters to the needs of those varied consumers. Read more...

I had the pleasure of writing an article for Nordic APIs on Web API definition languages. If you’re into the world of Web APIs, you’ve probably heard of formats like Swagger, RAML or API Blueprint. They allow developers to define the contract of the API, with its endpoints, its resources, its representations, allowed methods, the kind of payloads it understands, the status codes returned, and more. With the contract of your Web API, you can generate code for your backend implementation or client kits, documentation for publishing the details of your API for your API consumers. Read more...