API Versioning as a Translation Layer
API versioning as an architecture: requests enter through a version header, pass through a chain of reversible version changes, and reach controllers that only ever see the latest model.
Loading…
Topic
REST APIs
80 posts about REST APIs. Every summary links to the original.
- 80 posts
- 18 companies
- 1 explainer
See the idea
REST APIs explainers
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Understanding GraphQL for Beginners–Part One
The article introduces GraphQL as an open-source data query and manipulation language for APIs, contrasting it with REST's fixed response shapes and multiple endpoint calls. GraphQL lets clients describe exactly which fields they need, returning that requested structure through a single endpoint rather than a cookie-cutter response. Using a Toronto Eagles example, the article explains how one GraphQL query can combine requests for a team's founding year, captain's name, and last championship, avoiding three separate RESTful trips whose latency can vary. It also uses burger and bank withdrawal analogies to explain over-fetching, under-fetching, flexible frontend iteration, and fewer endpoints, then points readers to a forthcoming Ruby on Rails implementation in part two.
Rate Limiting GraphQL APIs by Calculating Query Complexity
Shopify’s GraphQL Admin API uses calculated query costs to address two limitations of request-based rate limiting: identical credits for responses of different sizes and equal treatment of reads and side-effecting writes. The server statically analyzes each query, assigning one point to objects and interfaces or unions, zero to scalars and enums, two plus the requested object count to connections, and 10 to mutations. Clients receive 50 points per second up to a 1,000-point limit, while responses expose requested and actual costs; when fewer connection records are returned, the difference is refunded. The post reports a linear correlation between calculated query complexity and execution time, giving Shopify more predictable load for infrastructure scaling and a way to identify performance outliers.
Few-shot learning in practice: GPT-Neo and the 🤗 Accelerated Inference API
Limited labeled data often prevents machine learning models from achieving high performance during traditional fine-tuning. Few-shot learning addresses this hurdle in natural language processing by supplying a short task description and a few demonstration examples at inference time. EleutherAI developed GPT-Neo, an open transformer-based model trained on the Pile dataset, which can execute few-shot tasks via the Hugging Face Accelerated Inference API. Compared to larger models like GPT-3, the 2.7B parameter version of GPT-Neo requires three to four examples alongside tuned hyperparameters like temperature and stopping sequences to generate accurate completions. Because few-shot learning relies heavily on pre-trained associations, careful output monitoring and human feedback mechanisms remain necessary to prevent automated bias.
Storage is now available in Supabase
Supabase launched Storage, adding a scalable object store to its existing Postgres, authentication, and API services. Existing open-source storage servers like Ceph, Swift, Minio, and Zenko were evaluated but rejected due to auth incompatibilities and external dependencies like etcd, MongoDB, and Kafka. Consequently, the team implemented a custom Storage API server built with Fastify and TypeScript behind the Kong gateway. Object metadata and access control reside directly in Postgres, leveraging Row Level Security policies written in SQL rather than a proprietary domain-specific language. Objects stream directly to managed backends like AWS S3 using Node streams with minimal in-memory buffering, accompanied by a default one-hour Cache-Control header.
Postgres as a CRON Server
Postgres databases can schedule and execute external webhook calls periodically by combining the pg_cron and pgsql-http extensions. When configured, pg_cron schedules recurring tasks using standard cron syntax directly inside the database engine. In conjunction, the pgsql-http extension dispatches HTTP requests such as GET, POST, PATCH, and DELETE to external endpoints within SQL queries. Because pg_cron relies on background workers that start one process per server loop iteration, scheduled jobs do not interfere with core postmaster tasks or external client connections. Administrators can monitor job status, review execution logs, and unschedule active tasks directly through dedicated cron schema tables and helper functions.
Faster TensorFlow models in Hugging Face Transformers
Hugging Face updated Transformers to improve the computational performance and robustness of its TensorFlow models, including BERT, RoBERTa, ELECTRA, and MPNet. In version 4.2.0, the optimized BERT implementation runs up to approximately 10 percent faster than Google's official implementation and twice as fast as Transformers release 4.1.1 when tested on a V100 GPU. The release also improves TensorFlow SavedModel generation by allowing flexible sequence lengths across runs, exposing all model inputs, and grouping hidden states or attention outputs into single tensors. In addition, users can customize serving signatures by subclassing models and decorating custom methods with explicit input specifications. Models exported to the SavedModel format can be packaged into Docker containers and served via TensorFlow Serving using either HTTP REST or gRPC APIs for production inference.
ShipIt! Presents: A Look at Shopify's API Health Report
On July 17, 2020, ShipIt! hosted a discussion of Shopify’s API Health Report with Shuting Chang, Robert Saunders, Karen Xie, and Vrishti Dutta. The tool was built to surface breaking changes affecting Shopify Partner apps, and the event presented its role alongside the work of the multidisciplinary team behind it. Related materials cover Shopify’s API versioning, including how Shopify manages versioning and breaking changes, plus GraphQL Admin API references, an explorer, and learning resources. The event information also directs questions about API versioning and upcoming migrations to monitored API forums, the Partner Dashboard Support Form, and ShopifyDevs on Twitter, while linking to Shopify Partners, Shopify Developers, and REST/HTTP API evolution material.
Supabase Alpha May 2020
Supabase announced its May 2020 alpha development updates following acceptance into a fully remote Y Combinator cohort and unexpected attention from Hacker News. Operating under a ship early and often philosophy, the team continued deploying functional changes despite ongoing alpha bugs and platform instability. This milestone includes a revamped user interface configured to support incoming product capabilities alongside an initial, experimental Table View designed to rival tools like Airtable. Furthermore, Supabase rolled out realtime listeners that allow developers to subscribe to database changes comparable to Firebase functionality. The platform also added instant RESTful APIs and auto-updating documentation generated dynamically by introspecting modifications to the underlying Postgres schema.
Supabase Alpha April 2020
The April 2020 alpha release of Supabase introduces developer tools designed to make Postgres as straightforward to use as Firebase. Users can configure a Postgres instance in less than two minutes and execute database queries directly from the dashboard interface. The platform provides auto-generated RESTful APIs along with auto-updating documentation created through database schema introspection. Development work also encompasses realtime listeners for database change subscriptions, query performance analysis tools, and connectors that route realtime updates to queues or webhooks. Supabase is not yet production ready, storing only GitHub usernames and emails while running for free under Digital Ocean's startup program.
Developer Platform updates Spring 20'
Zoom introduced several updates across its developer platform alongside new roadmap milestones for 2020. Marketplace enhancements include a Developer Dashboard tracking install numbers and API usage, as well as dynamic OAuth scope configurations that distinguish mandatory and optional permissions. For client development, the WebSDK adds Microsoft Edge Chromium compatibility with video and VOIP support, whereas the iOS SDK incorporates Xcode 11 support. Due to increased developer demand, Zoom updated its V2 REST API rate limits and delivered new chat webhooks tracking message, channel, and member activity. Upcoming platform initiatives include the permanent termination of all legacy V1 APIs on May 31, 2020, platform security enhancements, and an iframe-free JavaScript embedding framework for the WebSDK.
Backwards Incompatible V2 API Changes
Following the removal of Zoom's Attention Tracking feature, backwards-incompatible modifications were introduced to the V2 REST API effective April 3, 2020. Under these deprecations, the attentiveness_score field in meeting and webinar participant reports returns an empty value, while the attention_tracking field across user, group, and account settings endpoints defaults to false. Both attention-tracking fields remain temporarily in API responses before full removal in a future release. Additionally, starting April 12, 2020, password-related configuration fields become immutable and permanently set to true for Free and single-host Pro K-12 Education accounts. These locking measures affect settings such as password requirements for scheduled, instant, or personal meetings, alongside PSTN password protection across account, group, and user endpoints.
New API Rate Limiter
Zoom announced an updated V2 REST API Rate Limiter launching in March 2020 to replace its previous one-size-fits-all throttling system. Rather than applying uniform constraints across all subscription tiers, the new framework cross-references customer Account Types against API Request Groups categorized by infrastructure importance and load intensity. While most API rate limits are increasing, resource-intensive Dashboard APIs are reduced from 1 request per second to 6 or 12 requests per minute depending on account level. Throttled HTTP 429 responses will return X-RateLimit-Reset timestamps for per-minute limits and ISO8601 Retry-After timestamps for per-day limits. Additionally, the system introduces lock-key restrictions on specific user identifier path variables to restrict concurrency and enforce daily meeting creation caps.
What’s New and What’s Coming for Zoom Marketplace in 2020?
Zoom announced several updates to its App Marketplace alongside roadmap deadlines scheduled for early 2020. Marketplace enhancements include functional app categories, additional URL fields for Terms of Use and documentation, and support for defining multiple webhook event subscriptions within a single application. Administrators and developers gained webhook logs, enhanced pre-approval permission settings, and the ability to test draft applications directly in the installed apps interface for Data Compliance API compliance. To accommodate surging traffic, Zoom introduced revamped V2 REST API rate limits and breaking behavioral changes to the List Users API. Crucially, the platform set an absolute end-of-life date of April 26, 2020, for all legacy V1 APIs, requiring immediate migration to V2 endpoints.
Zoom Developer Relations — Meet the Team
Zoom's Developer Relations team supports third-party developers, manages the App Marketplace, and maintains platform tools including APIs and Web SDKs. The team comprises technical writers, developer advocates, developer educators, security engineers, and marketplace specialists. Specific responsibilities include authoring integration documentation, reviewing early API designs, testing webhooks, scheduling security evaluations for Marketplace applications, and building sample code. Developer interactions take place across multiple channels, including the Zoom Developer Forum, Zendesk support tickets, Zoom meetings, app submission review notes, and partnership calls. Specialists also guide creators through the formal app submission lifecycle, reviewing functional workflows, privacy statements, and regional ISV opportunities across global markets like APAC.
Marionette - Enabling E2E User-scenario Simulation
Conducting end-to-end testing across Grab's transport microservices became difficult due to service availability, environment construction, cross-service authentication, and complex data setups for real-world user accounts. To address these challenges without relying on physical mobile devices or emulators, Grab built Marionette, an internal simulation platform for passenger and driver interactions. The platform provisions required test data, coordinates booking lifecycles, and isolates test executions across distinct user groups using localized cohorts. Engineers can configure driver and passenger behaviors, execute workflows, and run load or integration tests through a dedicated user interface, a Go SDK, and RESTful APIs.
Pagination with Relative Cursors
Incremental page-number pagination becomes increasingly expensive for large offsets, because the database scans and discards earlier records before returning a page. Shopify describes relative cursor pagination, which remembers the last record seen and continues from that point, using an indexed id to keep query time nearly constant as pages increase. In tests on a shop with 14 million products, a 100,000 offset took 2,221.60 ms, compared with 5.24 ms using the last id, while offsets of 1,000,000 and above consistently timed out. Sorting by another field requires retaining both its last value and a unique secondary key such as id, with a matching compound index to avoid skipped records and maintain performance. Shopify introduced Link-header URLs for next and previous pages and began migrating REST endpoints from page numbers, reporting early /admin/products.json usage as about 11 times faster, though adoption remained low and full results were pending.
Designing Resilient Systems: Circuit Breakers or Retries? (Part 2)
Retries enable software systems to recover from transient upstream failures by automatically repeating unsuccessful requests. While retrying increases the chance of request completion across multi-host setups, it consumes additional CPU and time without inherently tracking host health. Applications must selectively retry errors with a likelihood of success, such as 500 and 503 status codes, while avoiding client-side failures like 400 or 401. To manage distributed systems safely, retries require idempotent operations or cryptographic nonces, along with backoff and jitter to prevent request stampedes. Tuning retry counts, timeouts, and delays is critical to cap the worst-case consumer response time.
This Rocket Ain't Stopping - Achieving Zero Downtime for Rails to Golang API Migration
Grab transitioned its public passenger app APIs from a legacy Rails application to a Golang service-oriented architecture to consolidate its codebase and engineering teams. Initial attempts to proxy traffic through a cloned Rails server via gRPC were abandoned after encountering TCP load imbalances during autoscaling events and memory leaks in the gRPC Ruby gem. The team pivoted to direct logic migration, porting Ruby logic directly into Go while decomposing modules into standalone services. Verification relied on log-based load testing and live shadow testing, where write operations were safely validated using mock data access layers that evaluated expected database outcomes. Production rollout progressed endpoint-by-endpoint using requests-per-second traffic throttling and prewarmed AWS Elastic Load Balancers before executing the final DNS switch.
Programmers Beware - UX is Not Just for Designers
Software engineers frequently overlook user experience when designing APIs, SDKs, and code-level functions. Usability issues arise across various technical interfaces, from mobile apps forced to coordinate multiple round-trip network calls to ambiguous function signatures that obscure boolean arguments. To counter this, engineers can apply a five-question discovery framework to identify user identity, core objectives, user capabilities, ways to reduce user burden, and familiar paradigms. Practical remedies include sacrificing strict RESTful separation to merge mobile endpoints, placing validation logic inside internal RPC servers, and replacing boolean arguments with explicitly named helper functions. Ultimately, treating calling systems, end users, and fellow programmers as users shifts implementation complexity from consumers to servers.
Getting started with the Force.com APIs for the Hackathon
With a Salesforce hackathon approaching, the guide introduces the Force.com APIs as a way to build applications using Salesforce1’s authentication, data storage, and business rule services. It compares native Salesforce1 applications, connected web applications using SOAP or REST, and three mobile patterns, including hybrid extensions, native iOS or Android clients, and a “force.com proxy” model. For hands-on setup, it recommends a free Developer Edition account and Salesforce Workbench, then explains OAuth2 web flow and password-plus-token login before showing Ruby with Restforce and Node.js with Nforce. The examples configure a Connected App, keep credentials in environment variables, query records with SOQL, and create Account records, providing a practical starting path for API integration.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.