API چیست: چرا برنامه‌نویسان بدون آن نمی‌توانند کار کنند؟

اولین باری که در یک پروژه‌ی فروشگاهی با API روبرو شدم، مسئله ساده به‌نظر می‌رسید: باید قیمت محصولات را از یک سرویس خارجی می‌گرفتم و در سایت نمایش می‌دادم. اما وقتی مستندات آن سرویس را باز کردم، با مجموعه‌ای از endpointها، هدرهای احراز هویت و ساختارهای JSON روبرو شدم که درک آن‌ها چند روز طول کشید. آن تجربه، نقطه‌ی شروع مسیر من در دنیای API بود. آن روز فهمیدم که API چیست را می‌توان در یک جمله توضیح داد، اما فهم عمیق آن، تفاوت بین یک توسعه‌دهنده‌ی معمولی و یک مهندس نرم‌افزار حرفه‌ای است. در این نوشته، همان مسیر یادگیری را با شما به اشتراک می‌گذارم؛ از تعریف پایه تا طراحی، امنیت و الگوهای واقعی که در پروژه‌های خودم به‌کار برده‌ام.

API مخفف Application Programming Interface است و در ساده‌ترین تعریف، یک قرارداد ارتباطی بین دو نرم‌افزار است. اما این تعریف رسمی، تصویر کامل را نشان نمی‌دهد. API در واقع یک زبان مشترک است که به دو سیستم مستقل اجازه می‌دهد بدون نیاز به دانستن جزئیات پیاده‌سازی یکدیگر، با هم صحبت کنند. اگر تازه با دنیای وب آشنا می‌شوید، توصیه می‌کنم ابتدا بک‌اند چیست و فرانت‌اند چیست را بخوانید تا جایگاه API در معماری کلی روشن شود.

API چیست؟ تعریف دقیق و کاربردی

API یک رابط برنامه‌نویسی است که به دو نرم‌افزار اجازه می‌دهد بدون نیاز به دانستن جزئیات درونی یکدیگر، با هم تعامل کنند. در نگاه عملی، API مجموعه‌ای از قواعد، توابع و endpointهاست که یک سرویس در اختیار مصرف‌کنندگانش قرار می‌دهد.

یک مثال ساده: وقتی در سایت شما، کاربری روی دکمه‌ی «ورود با گوگل» کلیک می‌کند، سایت شما با API گوگل صحبت می‌کند. شما نیازی ندارید بدانید گوگل چطور رمزها را ذخیره می‌کند یا دیتابیسش چه ساختاری دارد؛ فقط از API او استفاده می‌کنید. این جداسازی، همان فلسفه‌ی وجودی API است.

سه ویژگی که هر API خوب دارد:

• قرارداد مشخص: API دقیقاً تعریف می‌کند که چه ورودی‌ای می‌پذیرد و چه خروجی‌ای می‌دهد.
• پنهان‌سازی پیاده‌سازی: مصرف‌کننده نیازی به دانستن جزئیات داخلی ندارد.
• استقلال: تغییرات داخلی سرویس، تا زمانی که قرارداد را نشکند، روی مصرف‌کننده اثر نمی‌گذارد.

API مثل قرارداد رسمی بین دو شرکت است: هرکدام می‌توانند داخل خودشان هر تغییری بدهند، اما تا زمانی که به توافق پایبند باشند، همکاری ادامه دارد.

مدل ذهنی: رستوران و گارسون

بهترین تشبیهی که برای فهم API در پروژه‌های آموزشی استفاده می‌کنم، رستوران است. شما به‌عنوان مشتری در یک رستوران، نمی‌توانید مستقیم وارد آشپزخانه شوید و غذا سفارش دهید. یک گارسون هست که سفارش شما را می‌گیرد، به آشپزخانه می‌برد، و پاسخ را برمی‌گرداند.

این مدل ذهنی، سه مزیت مهم API را هم روشن می‌کند: کلاینت نیازی ندارد آشپزخانه را بشناسد، آشپزخانه می‌تواند بدون اطلاع مشتری تغییر کند، و اگر یک گارسون (نسخه‌ی API) عوض شود اما منو ثابت بماند، تجربه‌ی مشتری تغییر نمی‌کند.

چرا دنیای امروز بدون API کار نمی‌کند؟

در ده سال گذشته، API از یک ابزار فنی به ستون فقرات دنیای دیجیتال تبدیل شده. سه دلیل که اهمیت API را در پروژه‌های واقعی نشان می‌دهد:

۱. جداسازی Frontend و Backend

در معماری مدرن، تیم frontend و تیم backend به‌طور مستقل کار می‌کنند. API قراردادی است که این استقلال را ممکن می‌کند. اگر با React یا Vue کار می‌کنید، تمام داده‌ها از API می‌آید. در پروژه‌های وردپرسی، این جداسازی هنوز کامل نیست اما به سمت WordPress REST API در حال حرکت است.

۲. اتصال به سرویس‌های خارجی

هر سرویس مدرن، API دارد: Stripe برای پرداخت، Twilio برای پیامک، Google Maps برای نقشه. اگر بخواهید این سرویس‌ها را در سایت خود ادغام کنید، باید با API آن‌ها کار کنید. راهنمای اتصال وردپرس به سرویس‌های خارجی مسیر عملی این کار را نشان می‌دهد.

۳. توسعه‌ی اپلیکیشن موبایل

وقتی یک اپلیکیشن موبایل می‌سازید، منطق کسب‌وکار روی سرور می‌ماند و اپلیکیشن با API صحبت می‌کند. این یعنی یک backend می‌تواند به اپلیکیشن iOS، اندروید و وب‌سایت هم‌زمان سرویس بدهد.

انواع API: از Web تا Library

اصطلاح API در جاهای مختلف، معنای متفاوتی دارد. جدول زیر یک نقشه‌ی سریع است:

در این نوشته، تمرکز روی Web API است چون بیشترین استفاده را در پروژه‌های وب دارد. برای مطالعه‌ی Browser APIها می‌توانید آموزش جاوااسکریپت از صفر را ببینید.

REST API: پرکاربردترین سبک امروز

REST (Representational State Transfer) یک سبک معماری برای طراحی APIهای وب است که در سال ۲۰۰۰ توسط Roy Fielding معرفی شد. اصول REST بر پایه‌ی منابع (resources) و متدهای استاندارد HTTP است.

مفاهیم کلیدی REST:

• Resource: هر چیزی که بتوان به آن نام داد و داده‌ای برای نمایش دارد (کاربر، محصول، سفارش).
• Endpoint: URL مشخصی که به یک resource اشاره می‌کند.
• Method: عملی که روی resource انجام می‌شود.
• Representation: فرمت داده‌ی برگشتی (معمولاً JSON).

متدهای استاندارد HTTP در REST:

مثال یک درخواست REST ساده:

GET /api/users/1 HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGc...

// پاسخ
{
  "id": 1,
  "name": "Ali",
  "email": "ali@example.com"
}

برای مطالعه‌ی عمیق REST، از جمله اصول طراحی، کدهای وضعیت و اشتباهات رایج، مقاله‌ی آموزش REST API مسیر کاملی است. اگر روی پروژه‌ای کار می‌کنید که از PHP استفاده می‌کند، ساخت API با PHP گام‌به‌گام راهنمای عملی است.

GraphQL: جایگزین یا مکمل؟

GraphQL یک زبان کوئری است که در سال ۲۰۱۵ توسط Facebook معرفی شد. تفاوت بنیادی آن با REST در نحوه‌ی دریافت داده است: در REST، هر endpoint یک ساختار داده‌ی مشخص برمی‌گرداند؛ در GraphQL، کلاینت دقیقاً مشخص می‌کند چه فیلدهایی می‌خواهد.

query {
  user(id: 1) {
    name
    email
    posts {
      title
    }
  }
}

در این کوئری، کلاینت دقیقاً می‌گوید چه فیلدهایی می‌خواهد. مزیت اصلی: حل مشکل Over-fetching (گرفتن داده‌ی اضافه) و Under-fetching (نیاز به چند درخواست). مقایسه‌ی کامل REST و GraphQL را در تفاوت REST و GraphQL نوشته‌ام.

اما یک نکته‌ی مهم: GraphQL جایگزین REST نیست. در پروژه‌های واقعی، معمولاً ترکیبی از هر دو استفاده می‌شود. REST برای endpointهای ساده و GraphQL برای داده‌های پیچیده.

آناتومی یک درخواست API

هر درخواست API از چهار بخش اصلی ساخته می‌شود:

1. URL/Endpoint: آدرسی که درخواست به آن فرستاده می‌شود.
2. Method: نوع عملیات (GET، POST و غیره).
3. Headers: اطلاعات اضافی مثل احراز هویت، نوع محتوا و زبان.
4. Body: داده‌ای که برای عملیات POST یا PUT فرستاده می‌شود (معمولاً JSON).

مثال کامل یک درخواست POST:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...

{
  "name": "Ali",
  "email": "ali@example.com"
}

کدهای وضعیت HTTP که در API زیاد استفاده می‌شوند:

احراز هویت در API

احراز هویت یکی از مهم‌ترین جنبه‌های API است. سه روش رایج:

۱. API Key

GET /api/data
Authorization: ApiKey abc123def456

ساده‌ترین روش. مناسب برای سرویس‌های داخلی یا APIهای عمومی با محدودیت کم. عیب: اگر کلید لو برود، همه‌چیز در خطر است.

۲. JWT (JSON Web Token)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

یک توکن خودبسنده که اطلاعات کاربر را در خودش دارد. مزیت: stateless، مناسب برای معماری microservices. راهنمای کامل در احراز هویت در API.

۳. OAuth 2.0

استانداردی برای احراز هویت مبتنی بر توکن که اجازه می‌دهد کاربران بدون دادن رمز خود، به سرویس‌های دیگر دسترسی بدهند. مثلاً وقتی با حساب گوگل خود وارد یک سایت می‌شوید، در واقع از OAuth استفاده می‌کنید.

در پروژه‌ای که یک پلتفرم SaaS داشتیم، استفاده از JWT باعث شد که بتوانیم بدون ذخیره‌ی session در سرور، احراز هویت را مدیریت کنیم. این تصمیم مقیاس‌پذیری سیستم را چند برابر افزایش داد.

امنیت API: لایه‌های فراموش‌شده

امنیت API از چند لایه تشکیل می‌شود که در پروژه‌ها معمولاً فقط یک یا دو لایه از آن‌ها پیاده‌سازی می‌شود:

• HTTPS: تمام ترافیک بین کلاینت و سرور باید رمزنگاری شود.
• Rate Limiting: محدود کردن تعداد درخواست‌ها از هر IP یا کاربر.
• Input Validation: اعتبارسنجی تمام داده‌های ورودی، حتی اگر کلاینت شما آن‌ها را فرستاده باشد.
• Authorization: بعد از احراز هویت، باید بررسی شود که کاربر مجاز به انجام این عملیات هست یا نه.
• Logging and Monitoring: ثبت تمام درخواست‌ها و پایش الگوهای مشکوک.

راهنمای کامل امنیت API در امنیت API آمده. اگر روی پروژه‌ای وردپرسی کار می‌کنید، هدرهای امنیتی HTTP لایه‌ی مهمی است که در پاسخ API هم باید تنظیم شود.

امنیت API مثل ساختن قلعه است: یک دیوار بلند کافی نیست؛ باید برج و بارو، خندق و نگهبان هم داشته باشید. هرچه لایه‌ها بیشتر، حمله سخت‌تر.

طراحی API خوب: اصول عملی

یک API خوب با سه اصل شناخته می‌شود:

1. پیش‌بینی‌پذیری: endpointها و ساختار پاسخ‌ها باید یک الگوی ثابت داشته باشند. مثلاً اگر برای کاربران از /api/users استفاده می‌کنید، برای محصولات هم /api/products منطقی است.
2. سازگاری با گذشته: تغییرات API نباید کلاینت‌های قدیمی را بشکند. راه‌حل: نسخه‌بندی در URL یا Header.
3. مستندسازی کامل: هر endpoint باید مستندات داشته باشد با مثال‌های واقعی. راهنمای کامل در مستندسازی API.

سه الگوی طراحی که در پروژه‌های خودم بیشترین استفاده را داشته‌اند:

۱. استفاده از Noun برای Resource

// خوب
GET /api/users
GET /api/users/1
GET /api/users/1/orders

// بد
GET /api/getUsers
GET /api/user-detail

۲. فیلتر و صفحه‌بندی با Query Parameters

GET /api/products?category=electronics&page=2&limit=20&sort=price

۳. نسخه‌بندی در URL

GET /api/v1/users
GET /api/v2/users

در پروژه‌ای که یک پلتفرم API عمومی داشتیم، نسخه‌بندی از روز اول به ما اجازه داد که بدون شکستن کلاینت‌های قدیمی، API را تکامل بدهیم. این یک تصمیم کوچک بود که در بلندمدت هزاران ساعت دیباگ و پشتیبانی ذخیره کرد.

الگوهای واقعی در پروژه‌ها

سه الگوی عملی که در پروژه‌های backend خودم به‌کار برده‌ام:

1. Response Wrapper Consistent: همه‌ی پاسخ‌های API یک ساختار ثابت داشته باشند:

{
  "success": true,
  "data": { ... },
  "meta": { "page": 1, "total": 100 }
}

// در صورت خطا
{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid email format",
    "field": "email"
  }
}

این الگو در پروژه‌های frontend باعث می‌شود که مدیریت خطا در کل اپلیکیشن یکدست باشد.

2. Batch Endpoints برای عملیات تکراری: اگر کلاینت نیاز به چند عملیات مشابه دارد (مثلاً ایجاد ده کاربر)، یک endpoint batch بسازید نه ده درخواست جداگانه.
3. Idempotency Key برای POSTهای حساس: در پرداخت‌ها، اگر کلاینت دوبار درخواست بفرستد (مثلاً به‌دلیل مشکل شبکه)، نباید دو تراکنش ایجاد شود. راه‌حل: کلاینت یک Idempotency Key می‌فرستد و سرور بررسی می‌کند که آیا این درخواست قبلاً پردازش شده یا نه.

برای مطالعه‌ی بیشتر در مورد تست API در محیط توسعه، تست API را ببینید. اگر با وردپرس کار می‌کنید و می‌خواهید API اختصاصی بسازید، ساخت API اختصاصی وردپرس راهنمای عملی است.

اشتباهاتی که در پروژه‌ها دیدم

• فقدان مستندات: API بدون مستندات، عملاً غیرقابل‌استفاده است. حتی اگر فقط خودتان از آن استفاده می‌کنید، سه ماه بعد فراموش خواهید کرد که endpoint کاربران چه پارامترهایی می‌گیرد.
• نبود نسخه‌بندی: در پروژه‌ای، API بدون نسخه‌بندی شروع شد و بعد از ۶ ماه، هر تغییر باعث شکستن کلاینت‌های دیگر می‌شد. مهاجرت به نسخه‌بندی در آن مرحله، بسیار دشوارتر شد.
• استفاده از GET برای عملیات تغییری: GET برای دریافت داده است، نه برای حذف یا ساخت. اگر GET /api/users/1/delete داشته باشید، ممکن است ربات‌های crawl باعث حذف تصادفی شوند.
• برگرداندن تمام دیتابیس در یک پاسخ: در پروژه‌ای، endpoint گزارش‌گیری، کل جدول سفارش‌ها را برمی‌گرداند. با رشد داده، پاسخ‌ها به چند مگابایت رسیدند و صفحه‌ی گزارش‌گیری غیرقابل‌استفاده شد. راه‌حل: صفحه‌بندی اجباری.
• عدم مدیریت خطا با کدهای وضعیت صحیح: استفاده از کد 200 برای پاسخ‌های خطا، مدیریت خطا در کلاینت را غیرممکن می‌کند.
• نبود Rate Limiting: بدون Rate Limiting، یک کاربر می‌تواند با چند درخواست ساده، سرور شما را زمین‌گیر کند. این یکی از پرتکرارترین حملات DoS ساده است.
• عدم اعتبارسنجی سمت سرور: اعتبارسنجی در frontend خوب است اما کافی نیست. هر داده‌ای که از سمت کلاینت می‌آید، ممکن است دستکاری شده باشد.
• لو دادن اطلاعات حساس در خطاها: برگرداندن stack trace کامل در production، اطلاعاتی مثل مسیر فایل‌ها و ساختار دیتابیس را به مهاجم نشان می‌دهد. راه‌حل: خطاهای عمومی در production، لاگ کامل در سرور.

لایه‌ای زیر سینتکس درخواست

اینجا وارد لایه‌ای می‌شوم که در پروژه‌های معمولی به آن نگاه نمی‌شود اما برای مهندسان پلتفرم و توسعه‌دهنده‌های ارشد اهمیت دارد. آنچه در یک درخواست API اتفاق می‌افتد، در پنج مفهوم خلاصه می‌شود:

1. HTTP/2 و HTTP/3 و Multiplexing: در HTTP/1.1، هر درخواست یک اتصال TCP جداگانه می‌خواست یا از connection pooling استفاده می‌کرد. HTTP/2 با multiplexing اجازه می‌دهد چندین درخواست روی یک اتصال هم‌زمان ارسال شوند و ترتیب پاسخ‌ها حفظ شود. HTTP/3 که بر پایه QUIC (روی UDP) است، این را به سطح بالاتری می‌برد و تأخیر را در شبکه‌های پرتلفات کاهش می‌دهد. اگر API شما روی HTTP/2 باشد و کلاینت هم پشتیبانی کند، تعداد کل درخواست‌ها می‌تواند چند برابر شود بدون سربار اضافه. مطالعه‌ی موازی این لایه در بهینه‌سازی سرعت سایت.
2. Idempotency و Property of HTTP Methods: در طراحی اصولی API، متدهای HTTP ویژگی‌های مشخصی دارند: GET، PUT و DELETE idempotent هستند (چند بار اجرا، نتیجه یکسان دارد)، POST idempotent نیست. این ویژگی به کلاینت اجازه می‌دهد در صورت شکست شبکه، درخواست را با اطمینان دوباره بفرستد. در معماری microservices، این ویژگی برای هماهنگی بین سرویس‌ها حیاتی است. مطالعه‌ی موازی در امنیت API.
3. Rate Limiting Algorithm و Fairness: پیاده‌سازی Rate Limiting با الگوریتم‌های مختلف انجام می‌شود: Fixed Window، Sliding Window، Token Bucket و Leaky Bucket. هرکدام trade-off خاصی دارند: Fixed Window ساده‌تر است اما در مرزها مشکل دارد؛ Sliding Window دقیق‌تر است اما حافظه‌ی بیشتری می‌خواهد. Token Bucket به کاربر اجازه می‌دهد در بازه‌ی کوتاه، burst داشته باشد. این تصمیم در APIهای پرترافیک، تفاوت بین یک سرویس قابل اعتماد و یک سرویس ناپایدار است. مطالعه‌ی موازی در هدرهای امنیتی HTTP.
4. Consistency Model در APIهای توزیع‌شده: وقتی API شما با چند دیتابیس یا سرویس کار می‌کند، بحث Strong Consistency و Eventual Consistency مطرح می‌شود. در معماری microservices، معمولاً به سمت Eventual Consistency حرکت می‌کنیم تا مقیاس‌پذیری حفظ شود. اما این یعنی گاهی یک کاربر ممکن است بعد از ارسال درخواست POST، در GET بعدی همان داده را نبیند. راه‌حل: خواندن از همان سرور (read-after-write consistency) یا استفاده از صف و event sourcing. این لایه، مرز بین معماری معمولی و معماری توزیع‌شده است. مطالعه‌ی موازی در بک‌اند چیست و آیا Node.js برای بک‌اند مناسب است.
5. Interaction با TypeScript و Type-Safe Client: در پروژه‌های مدرن، APIها به تدریج به سمت قراردادهای تایپ‌شده حرکت می‌کنند. ابزارهایی مثل tRPC و GraphQL Codegen، تایپ‌های TypeScript را از سمت سرور به سمت کلاینت منتقل می‌کنند. یعنی وقتی endpoint تغییر می‌کند، کامپایلر کلاینت خطا می‌دهد و جلوی خطاهای runtime را می‌گیرد. این یک تحول بزرگ در توسعه‌ی fullstack است که ریشه‌اش در ترکیب API با سیستم‌های تایپ قوی مثل TypeScript است. مطالعه‌ی موازی در تایپ اسکریپت با Node.js و آموزش تایپ اسکریپت از صفر.

یک تجربه‌ی واقعی از پروژه‌ای که با Consistency Model مواجه شدیم: در یک پلتفرم فروشگاهی، بعد از افزودن قابلیت «ایجاد سفارش سریع»، کاربران شکایت کردند که بعد از ثبت سفارش، لیست سفارش‌هایشان آن را نشان نمی‌دهد. ریشه: سیستم از یک replica دیتابیس می‌خواند که lag داشت. راه‌حل: بعد از ایجاد سفارش، به‌مدت ۵ ثانیه، درخواست‌های GET همان کاربر از replica اصلی خوانده می‌شدند. این یک الگوی read-after-write consistency است که در تمام سیستم‌های توزیع‌شده ضروری است.

اگر روی پروژه‌های وردپرسی هستید و می‌خواهید این لایه‌ها را در development pipeline خود اعمال کنید، پیشنهاد می‌کنم ابتدا به توسعه وردپرس از صفر نگاهی بیندازید. برای مطالعه‌ی موازی با استانداردها و معماری، استانداردهای HTML و CSS و CSS مدرن از Flexbox تا Grid دید وسیع‌تری می‌دهند. برای درک این لایه در چارچوب کارایی، بهینه سازی جاوااسکریپت و بهینه‌سازی سرعت سایت منابع کلیدی هستند. اگر روی معماری backend متمرکز هستید، بک‌اند چیست، تفاوت فریم‌ورک‌های بک‌اند و آیا Node.js برای بک‌اند مناسب است دید وسیع‌تری می‌دهند.

API در لایه‌ی سطح، یک قرارداد ارتباطی است؛ در لایه‌ی عمیق، یک تصمیم معماری درباره‌ی نحوه‌ی تفکر شما درباره‌ی داده، امنیت و مقیاس‌پذیری.

ایستگاه پایانی این مسیر

API را می‌توان در یک جمله خلاصه کرد: «قراردادی که به دو نرم‌افزار اجازه می‌دهد بدون دانستن جزئیات درونی یکدیگر، با هم صحبت کنند.» سه درس که از این مسیر با خودم بردم:

1. API را به‌عنوان محصول ببینید، نه ابزار داخلی. اگر API شما برای دیگران هم قابل استفاده است، آن را مثل یک محصول طراحی کنید: مستندات کامل، نسخه‌بندی، پایداری و سازگاری با گذشته. تفاوت بین یک API آماتور و یک API حرفه‌ای، در همین نگاه نهفته است.
2. امنیت API یک لایه نیست، مجموعه‌ای از لایه‌هاست. HTTPS، احراز هویت، مجوزدهی، Rate Limiting، اعتبارسنجی ورودی و لاگ‌گیری، همه با هم یک سیستم امن می‌سازند. نبود حتی یک لایه، کل سیستم را در معرض خطر قرار می‌دهد.
3. طراحی اصولی، هزینه‌ی آینده را کاهش می‌دهد. تصمیم‌های کوچک در طراحی API — مثل نسخه‌بندی در URL، استفاده از کدهای وضعیت صحیح، ساختار یکدست پاسخ‌ها — در بلندمدت تفاوت بین یک سیستم قابل نگهداری و یک سیستم شکننده را می‌سازند.

مسیر یادگیری وب با این نوشته تمام نمی‌شود. اگر می‌خواهید مرحله‌ی بعدی را بردارید، آموزش REST API، احراز هویت در API و امنیت API سه قدم منطقی بعدی هستند. اگر روی پروژه‌های وردپرسی متمرکز هستید، API در وردپرس، ساخت API اختصاصی وردپرس و اتصال وردپرس به سرویس‌های خارجی منابع کلیدی هستند. اگر هم به سمت معماری و توسعه‌ی fullstack می‌روید، بک‌اند چیست، تفاوت فرانت‌اند و بک‌اند و فول‌استک چیست دید وسیع‌تری می‌دهند.

در تجربه‌ی خودم، API همیشه یکی از آن موضوعاتی است که در نگاه اول ساده به‌نظر می‌رسد اما در عمق، بی‌پایان است. اگر شما هم با یک مورد عجیب در طراحی یا استفاده از API روبرو شده‌اید — از یک الگوی خاص که مقیاس‌پذیری را چند برابر کرد، تا یک اشتباه در Rate Limiting که سرویس را زمین‌گیر کرد — آن را با ما در میان بگذارید. آن نوع روایت‌ها، برای کسی که امروز در حال طراحی اولین API خودش است، از هر مستند رسمی ارزش عملی بیشتری دارند.