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). There are useful libraries like Resilience4j that you can configure for Micronaut web controllers, or Bucket4j for your Spring controllers.

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

You have to pass the data, and also pass headers to specify the content-type. You can make it slightly shorter with the one-letter flags:

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. As I’ve been interested in Web APIs for a long time, I decided to look into this topic a bit more, by working on a new talk.

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. Specifically, the extensibility of API specifications with additional elements and feature sets comes into question.

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. Beyond any ideal design of your API, reality strikes back with the concrete and differing concerns of varied API consumers. You might need to optimize your API accordingly.