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...

As cURL was celebrating its 25th birthday, I was reading Daniel Stenberg’s story behind the project, and discovered a neat little feature I hadn’t heard of before: the --json flag! Daniel even blogged about it when it landed in cURL 7.82.0 last year. So what’s so cool about it? If you’re like me, you’re used to post some JSON data with the following verbose approach: curl --data '{"msg": "hello"}' \ --header "Content-Type: application/json" \ --header "Accept: application/json" \ https://example. Read more...

You’ve certainly interacted with webhooks at some point: with a Github commit webhook, for Slack or Dialogflow chatbots, for being notified of Stripe payments, or when you receive an SMS via Twilio. The concept is fairly well known, but there are some roadblocks along the way, whether you implement a webhook handler (the URL being called) or a webhook backend (the service notifying URLs). It’s not necessarily as trivial as it may first seem. Read more...

The most common API definition languages we spot in the wild are Swagger / OpenAPI Spec, RAML and API Blueprint. All three let you define your endpoints, your resources, your query or path parameters, your headers, status codes, security schemes, and more. In a nutshell, these definition languages define the structure of your API, and allow you to describe many elements. As standards in the API industry evolve, however, their purpose and design are under continuous scrutiny. Read more...

An interesting trend is emerging in the world of Web APIs, with various engineers and companies advocating for dedicated APIs for each consumer with particular needs. Imagine a world where your system needs to expose not only one API for iOS, one API for Android, one for the website, and one for the AngularJS app front end, but also APIs for various set-top boxes and exotic mobile platforms or for third-party companies that call your API. Read more...