Modern software are built on API-first policy. Without APIs your product is isolated in its own boundaries. In this post I disucss essential things you need to engineer your APIs elegantly and build robust systems.
Well-crafted APIs
β¨ Check this post on A survival kit to beat APIs interview by Raul Junco. Though this article is written in an βinterview prepβ way, but itβs a masterpiece on elegant API design and engineering, covering nearly all the important topics.
β
CRUD operations and HTTP verb
β
HTTP status codes and the ones which are most frequently used
β
Stateless APIs
β
Different ways you can secure your APIs using AuthN and AuthZ, rate limiting, input validation, HTTPS and encrypting data on storage
β
API Keys (for application identification) vs tokens (for user identification)
β
Versioning your APIs either by URL based versioning or using custom headers
β
Pagination using limit-offset, cursor, page numbers or keysets
β
Rate Limiting and why it is important
β
Idempotency and ensuring it with an IdempotencyKey
added by the client for each request, that violates a unique constraint on the database when executed more than once
β
Ways to make your APIs faster using caching on the client, server, or CDN, distributed caching, query optimization, connection pooling, data serialization and compressiong
β
Documenting APIs using OpenAPI (Swagger) including endpoint descriptions, req-res examples, query parameters, headers, error codes, etc
Secure your APIs
β¨ Next, this post on Siz strategies to build secure APIs by Saurabh Dashora. Must read! Describes six strategies that help you bullet-proof your APIs:
β
Using HTTPs
β
Rate limiting and throttling
β
Validation of inputs
β
AuthN and AuthZ
β
Role-based access control (RBAC)
β
Monitoring and logging
Manage transactions
β¨ We canβt imagine a software system that doesnβt use a database.. and with database, comes the responsibility to manage data and transactions. Another article by Raul Junco on Transaction Isolation.
β
What transactions are
β
Read Write anomalies: Dirty reads, non-repeatable reads, phantom reads and write skew
β
Transaction Isolation Levels: Read uncommitted, read committed, repeatable read and serializable.
β
Performance trade-offs
β
Choosing isolation levels
Well maintained caching
β¨ Improving application and API performance need caching. We need to cache data at many levels. This can quickly start becoming an overhead as we cache more and more data. Wisdom says, you cache what is frequently required, and remove anything thatβs not required often. However, as scenarios call for it, there could be needs for different strategies. Read on Seven cache eviction strategies by Ashish Pratap Singh.
β
Least recently used (LRU)
β
Least frequently used (LFU)
β
First In, First Out (FIFO)
β
Random replacement (RR)
β
Most recently used (MRU)
β
Time to live (TTL)
β
Two-tiered caching
Deal with entropy
β¨ Like any other machine, software (an intangible machine with moving parts) quality and maintainability degrade overtime. I asked ChatGPT for a very short summary on Software Entropy:
In software, entropy refers to the increasing disorder, complexity, or unpredictability within a system over time. In software design, high entropy means the code becomes harder to understand, maintain, or extend, often due to quick fixes, poor documentation, or lack of refactoring. This leads to software rot and reduced reliability.
Read on how to Embrace Software Entropy by Petar Ivanov.
β
Accept that change is inevitable
β
Build for now (very very very important!)
β
Stay flexible
β
Embrace entropy
The software industry has many people of wisdom who write technical articles like above. Thanks to all the authors. I try to collect such well crafted knowledge articles and document them on this blog.