Every few weeks someone asks whether MCP replaces REST. It does not. The question is still worth answering carefully, because the line between the two moved in July, and most of the explanations written before then are now describing a protocol that no longer exists.

An HTTP API is a contract between two pieces of software written by people who read documentation. A developer opens the reference, learns that POST /v1/invoices wants a customer ID and an array of line items, writes the call, and ships it. The knowledge lived in a human head at build time and then got frozen into source code. When the endpoint changes, something breaks in production and a person goes and fixes it.

Sixty-six sites, 18,880 visits and 19,950 page views for the week of August 30 to September 5. Visits rose 14.91% and page views 17.01%, which is a good week by any reading of the top line. The median page load time across the network went the other way, climbing 28.64% to 3,579ms, and that single figure complicates the rest of the report.

technologies.org led again with 2.44k visits and 2.52k page views, up 74.29% and 76.22% respectively, on a load time of 2,561ms (up 8.8%). Chrome accounted for 1.32k of those sessions against 1.05k logged as Unknown, with a further 30 from ChromeMobileWebview. Its LCP at the 75th percentile improved by a third to 2,704ms even as the raw load time crept up, so the main content is painting faster while the tail of the load stretches out. CLS came in at 1, up 262.32%, and INP at 40ms. In second place, marketresearchmedia.com posted 1.17k visits and 1.17k page views, both up 265.62%, making it the largest mover in the report and also its worst performer on speed: load time nearly tripled to 7,454ms and the 75th percentile LCP went up almost fivefold to 4,988ms. Chrome carried 1.02k of those sessions, Unknown 110, ChromeMobile 10. Visits and page views are identical, so every session ended on the page it began on. Third, analysis.org held steady at 1.1k visits (up 8.91%) and 1.12k page views (up 9.8%), and delivered the clearest genuine improvement in the report with a load time down 21.99% to 3,579ms after weeks in five figures. Its LCP eased 10.42% to 3,680ms, CLS sat flat at 1, INP at 40ms. Unusually for the top three, Unknown outnumbered Chrome here, 660 to 390, with 20 on ChromeMobile.

Authentication is where most API integrations go wrong the first time. Not because the concepts are complicated, but because there are several distinct mechanisms in common use, they solve different problems, and developers often reach for the one they recognize rather than the one that fits. Understanding what each mechanism actually does — and what it does not do — is the difference between an integration that works and one that works until it doesn’t.

Every API feature eventually reaches the end of its useful life. The endpoint was designed before the domain was understood. The schema made assumptions that no longer hold. A better approach exists. The old version must go. How you handle that retirement determines whether your API’s integrators trust you or resent you.

Deprecation done well is a communication and scheduling problem. Deprecation done poorly is a breaking change that happens without warning.

Errors are not edge cases in API development. They are a primary output. Every API call that can fail will fail — due to invalid input, authentication problems, resource conflicts, rate limits, or infrastructure issues — and how an API communicates those failures determines whether integrators can handle them gracefully or are left guessing. An API that returns clear, consistent, actionable errors is a well-designed API. Everything else is guesswork at scale.

An API gateway is a server that sits between clients and backend services, acting as the single entry point through which all API traffic passes. Every request goes through the gateway, which can inspect, modify, authenticate, route, transform, and rate-limit that traffic before it reaches any backend service. For teams running multiple services, an API gateway centralizes concerns that would otherwise be duplicated across every service independently.

Understanding what a gateway provides — and what it does not — is the prerequisite to deciding whether one belongs in your architecture.

Every API integration has a bootstrap problem. To build against an API, you need to call it. To call it safely during development, you need an environment that will not charge your card, send real emails, or bill real users. To build that environment, you need to understand how the API works — which requires calling it. This circularity is why sandboxes and mocks exist, and why both are worth understanding deeply.

APIs that external developers pay to use require more than good technical design. They require a pricing model that aligns cost with value, metering infrastructure that accurately tracks usage, and billing systems that translate usage into charges reliably. These are product and engineering concerns that compound — a poorly designed pricing model produces integrators who spend more time managing API costs than building their product, and metering infrastructure that loses events produces disputes and lost revenue.

An API that works in development and fails in production in ways you cannot diagnose is worse than an API that fails loudly. Production is where assumptions meet reality, and the gap between them only becomes visible if you can see what is happening inside the system. Observability is the discipline of making distributed systems understandable — building in enough visibility that when something goes wrong, you can find out what, where, and why without guessing.

Returning a list of items from an API sounds simple until the list has ten thousand items. At that point, the response is too large to transfer efficiently, too slow to serialize, and too expensive to compute. Pagination is how APIs break large result sets into manageable chunks that clients can fetch incrementally. Choosing the wrong pagination pattern — or implementing the right one incorrectly — creates problems that do not appear until production load reveals them.