<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>REST on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/rest/</link><description>Recent content in REST on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 15 Jul 2025 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/rest/index.xml" rel="self" type="application/rss+xml"/><item><title>System Design (3): API Design — REST, gRPC, GraphQL, and Choosing Wisely</title><link>https://www.chenk.top/en/system-design/03-api-design/</link><pubDate>Tue, 15 Jul 2025 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/system-design/03-api-design/</guid><description>&lt;p>In 2015, Facebook published a blog post introducing GraphQL, describing how their mobile app was drowning in REST API calls. A single news feed screen required data from posts, users, comments, likes, and media — each a separate endpoint, each returning far more data than the client needed. The over-fetching was killing mobile performance on slow networks. GraphQL was their solution, but it was not a universal solution.&lt;/p>
&lt;p>Every API style exists because it solves a specific set of problems well, and every API style creates new problems. The skill is matching the right protocol to the right context.&lt;/p></description></item></channel></rss>