سوالات مصاحبه طراحی API سطح سینیور (50 سوال)

Question 1

چرا توصیه می‌شود cursor در API عمومی یک رشته opaque (مثلاً base64 رمزشده) باشد نه یک `id` خام؟

Accepted Answer

تا بتوان پیاده‌سازی (کلیدهای sort، ساختار) را بعداً بدون شکستن کلاینت‌ها تغییر داد

Answer

چون base64 داده را در برابر هر نوع دستکاری امن می‌کند

Answer

چون دیتابیس‌ها فقط رشته‌های base64 را در `WHERE` می‌پذیرند

Answer

چون cursorهای عددی در JSON قابل نمایش نیستند

Question 2

در پیاده‌سازی idempotency key، اگر درخواست دوم با همان کلید ولی body متفاوت برسد، رفتار درست چیست؟

Accepted Answer

رد کردن با خطا (مثلاً `422` یا `409`) چون کلید برای payload دیگری استفاده شده است

Answer

اجرای درخواست جدید و بازنویسی نتیجه قبلی

Answer

برگرداندن بی‌صدای پاسخ قبلی بدون هیچ هشدار

Answer

حذف کلید و اجرای هر دو درخواست

Question 3

در سیستم‌های توزیع‌شده، تحویل «exactly-once» پیام‌ها/درخواست‌ها معمولاً چگونه به دست می‌آید؟

Accepted Answer

با تحویل at-least-once همراه پردازش idempotent یا deduplication در گیرنده

Answer

با استفاده از TCP که تحویل exactly-once را تضمین می‌کند

Answer

با غیرفعال کردن همه retryها در کلاینت

Answer

با HTTP/2 که درخواست‌های تکراری را حذف می‌کند

Question 4

یک کلاینت مخرب query تودرتو مثل `friends { friends { friends { ... } } }` می‌فرستد. مؤثرترین دفاع چیست؟

Accepted Answer

محدودیت عمق و تحلیل هزینه (query cost) قبل از اجرا، همراه rate limit مبتنی بر هزینه

Answer

محدود کردن تعداد درخواست HTTP در دقیقه بدون توجه به محتوای query

Answer

فعال کردن gzip روی پاسخ‌ها

Answer

تبدیل همه فیلدها به non-null

Question 5

persisted queries در GraphQL چه مزایایی دارند؟

Accepted Answer

ارسال hash به جای متن query، امکان `GET` و cache در CDN و allowlist کردن queryهای مجاز

Answer

ذخیره پاسخ‌ها در دیتابیس برای همیشه

Answer

حذف نیاز به resolver در سرور

Answer

تبدیل خودکار queryها به mutation

Question 6

در Apollo Federation، چطور سرویس Reviews فیلد `reviews` را به type `User` که مالکش سرویس Accounts است اضافه می‌کند؟

Accepted Answer

`User` را به‌عنوان entity با `@key(fields: "id")` تعریف و در subgraph خودش extend می‌کند؛ router با reference resolver ترکیب می‌کند

Answer

Reviews مستقیماً به دیتابیس Accounts متصل می‌شود و جدول users را می‌خواند

Answer

کل schema در یک فایل مشترک نوشته و در هر دو سرویس کپی می‌شود

Answer

کلاینت دو query جداگانه می‌فرستد و نتایج را خودش join می‌کند

Question 7

چرا HTTP caching در GraphQL نسبت به REST سخت‌تر است و کلاینت‌هایی مثل Apollo چطور جبران می‌کنند؟

Accepted Answer

همه چیز معمولاً `POST` به یک endpoint است؛ کلاینت cache نرمال‌شده بر اساس `__typename` و `id` می‌سازد

Answer

پاسخ‌های GraphQL باینری هستند و قابل cache نیستند

Answer

GraphQL هدرهای HTTP را پشتیبانی نمی‌کند

Answer

مشخصات GraphQL caching را صراحتاً ممنوع کرده است

Question 8

رویکرد رایج برای تکامل schema GraphQL به جای versioning (`/v2/graphql`) چیست؟

Accepted Answer

افزودن فیلدهای جدید، علامت‌گذاری قدیمی‌ها با `@deprecated` و حذف بعد از رسیدن استفاده به صفر طبق field-level metrics

Answer

تغییر نام فیلدها در محل و اطلاع‌رسانی با ایمیل

Answer

ساختن یک schema کاملاً جدید برای هر release

Answer

غیرفعال کردن introspection تا کلاینت‌ها متوجه تغییرات نشوند

Question 9

کدام تغییر در یک پیام protobuf که کلاینت‌های قدیمی هنوز از آن استفاده می‌کنند، breaking است؟

Accepted Answer

تغییر نوع فیلد `3` از `string` به `int64`

Answer

اضافه کردن فیلد جدید با شماره استفاده‌نشده `7`

Answer

تغییر نام فیلد بدون تغییر شماره (در encoding باینری)

Answer

حذف یک فیلد و `reserved` کردن شماره آن

Question 10

در proto3، چطور می‌توان تشخیص داد فیلد `int32 discount` توسط کلاینت ارسال نشده یا صراحتاً `0` بوده است؟

Accepted Answer

فیلد را `optional` تعریف کنید (یا از wrapper type مثل `Int32Value` استفاده کنید) تا presence ردیابی شود

Answer

مقدار `0` همیشه یعنی ارسال نشده و نیازی به کاری نیست

Answer

از `required` استفاده کنید که در proto3 پیشنهاد می‌شود

Answer

شماره فیلد را منفی کنید تا null پذیر شود

Question 11

چرا یک L4 load balancer معمولی در Kubernetes بار gRPC را بین podها نامتوازن پخش می‌کند؟

Accepted Answer

gRPC روی یک اتصال HTTP/2 طولانی‌مدت multiplex می‌کند و L4 فقط اتصال‌ها را پخش می‌کند، نه درخواست‌ها

Answer

gRPC از UDP استفاده می‌کند که L4 آن را پشتیبانی نمی‌کند

Answer

protobuf باعث می‌شود همه درخواست‌ها hash یکسانی داشته باشند

Answer

Kubernetes به‌طور پیش‌فرض ترافیک gRPC را مسدود می‌کند

Question 12

HTTP/3 کدام مشکل باقی‌مانده در HTTP/2 را حل می‌کند؟

Accepted Answer

head-of-line blocking در سطح TCP؛ با QUIC روی UDP، گم شدن یک packet فقط stream خودش را متوقف می‌کند

Answer

نبود multiplexing در HTTP/2

Answer

عدم پشتیبانی HTTP/2 از TLS

Answer

نبود فشرده‌سازی header در HTTP/2

Question 13

TLS 1.3/QUIC امکان ارسال داده در 0-RTT را می‌دهد. چرا سرورها معمولاً فقط درخواست‌های safe را در 0-RTT می‌پذیرند؟

Accepted Answer

داده 0-RTT می‌تواند توسط مهاجم replay شود، پس یک `POST` ممکن است دو بار اجرا شود

Answer

داده 0-RTT اصلاً رمزنگاری نمی‌شود و قابل خواندن است

Answer

0-RTT فقط از متد `GET` در سطح پروتکل پشتیبانی می‌کند

Answer

0-RTT باعث می‌شود پاسخ‌ها قابل cache نباشند

Question 14

امضای HMAC روی body به تنهایی جلوی کدام حمله را نمی‌گیرد و راه‌حل چیست؟

Accepted Answer

replay attack؛ timestamp را در محتوای امضاشده قرار دهید و درخواست‌های خارج از پنجره زمانی را رد کنید

Answer

XSS؛ با escape کردن body قبل از امضا

Answer

SQL injection؛ با امضای query دیتابیس

Answer

CSRF؛ با افزودن cookie به درخواست webhook

Question 15

سرویس باید بعد از commit سفارش در دیتابیس، webhook `order.created` را حتماً ارسال کند. چه الگویی از گم شدن رویداد جلوگیری می‌کند؟

Accepted Answer

transactional outbox: نوشتن رویداد در جدول outbox در همان تراکنش و ارسال توسط یک worker جداگانه

Answer

ارسال webhook قبل از commit تراکنش

Answer

ارسال webhook در یک `setTimeout` بعد از پاسخ به کاربر

Answer

دو بار ارسال webhook برای اطمینان

Question 16

رویدادهای `subscription.updated` ممکن است خارج از ترتیب برسند. طراحی مقاوم برای گیرنده چیست؟

Accepted Answer

استفاده از version/timestamp رویداد برای نادیده گرفتن قدیمی‌ها، یا fetch وضعیت فعلی از API با دریافت هر رویداد

Answer

اعمال هر رویداد به همان ترتیبی که رسیده است

Answer

رد کردن رویدادها با `500` تا به ترتیب دوباره ارسال شوند

Answer

فرض اینکه ارائه‌دهنده ترتیب را تضمین کرده است

Question 17

با rate limit پنجره ثابت «۱۰۰ درخواست در دقیقه»، کلاینت چطور می‌تواند در عمل ۲۰۰ درخواست در چند ثانیه بفرستد؟

Accepted Answer

۱۰۰ درخواست در انتهای یک پنجره و ۱۰۰ در ابتدای پنجره بعدی؛ sliding window این را حل می‌کند

Answer

با ارسال درخواست‌ها روی HTTP/2 که شمارش نمی‌شوند

Answer

با استفاده از متد `HEAD` که هرگز محدود نمی‌شود

Answer

این ممکن نیست؛ fixed window دقیق است

Question 18

API روی ۲۰ instance اجرا می‌شود و rate limit فعلی in-memory در هر instance است. مشکل و راه‌حل رایج چیست؟

Accepted Answer

سقف واقعی تا ۲۰ برابر می‌شود؛ از یک store مشترک مثل Redis با عملیات اتمیک (مثلاً Lua script) استفاده کنید

Answer

هیچ مشکلی نیست چون load balancer درخواست‌ها را به‌طور مساوی پخش می‌کند

Answer

باید rate limit را کاملاً حذف کرد چون در سیستم توزیع‌شده ممکن نیست

Answer

باید همه درخواست‌ها را به یک instance فرستاد

Question 19

در یک API چندمستأجری (multi-tenant) B2B، rate limit بهتر است بر چه اساسی باشد؟

Accepted Answer

شناسه tenant/API key (و در صورت نیاز per-endpoint)، تا یک مشتری پرمصرف بقیه را تحت تأثیر قرار ندهد

Answer

فقط آدرس IP، چون همه مشتریان IP ثابت دارند

Answer

یک سقف سراسری برای کل API بدون تفکیک

Answer

مقدار هدر `User-Agent`

Question 20

تیم‌ها شروع کرده‌اند منطق تبدیل داده و قواعد کسب‌وکار را در پیکربندی API gateway بنویسند. ریسک اصلی چیست؟

Accepted Answer

gateway به یک monolith مشترک و گلوگاه deploy تبدیل می‌شود و ownership سرویس‌ها مبهم می‌شود

Answer

gateway دیگر نمی‌تواند TLS را terminate کند

Answer

درخواست‌ها به‌طور خودکار رمزنگاری نمی‌شوند

Answer

هیچ ریسکی ندارد؛ gateway جای مناسبی برای منطق کسب‌وکار است

Question 21

مهم‌ترین trade-off الگوی BFF چیست؟

Accepted Answer

UI بهینه و استقلال تیم frontend در برابر تکرار کد و سرویس‌های بیشتر برای نگه‌داری

Answer

امنیت بالاتر در برابر عدم پشتیبانی از HTTPS

Answer

سرعت بیشتر در برابر عدم امکان cache

Answer

سادگی در برابر عدم امکان استفاده از REST

Question 22

با media type versioning (`Accept: application/vnd.x.v2+json`)، چه چیزی برای سازگاری با CDN ضروری است؟

Accepted Answer

ارسال `Vary: Accept` و اطمینان از اینکه CDN هدر `Accept` را در cache key لحاظ می‌کند

Answer

غیرفعال کردن کامل HTTPS

Answer

تغییر URL برای هر نسخه

Answer

هیچ کاری لازم نیست چون CDNها همه هدرها را در نظر می‌گیرند

Question 23

چطور می‌توان در یک سازمان بزرگ جلوی merge شدن تصادفی breaking changeها در REST APIها را گرفت؟

Accepted Answer

diff خودکار spec OpenAPI با نسخه منتشرشده در CI (مثلاً oasdiff) و fail کردن PR در صورت breaking change

Answer

اتکا به code review انسانی به تنهایی

Answer

افزایش coverage تست‌های unit سمت سرور

Answer

انتشار هر تغییر به‌عنوان major version جدید

Question 24

در یک معماری با ۴۰ microservice، چرا contract testing اغلب بر E2E testing کامل ترجیح داده می‌شود؟

Accepted Answer

E2E کند، شکننده و نیازمند محیط کامل است؛ contract test هر جفت consumer/provider را مستقل و سریع بررسی می‌کند

Answer

contract testing نیاز به هر نوع تست دیگری را حذف می‌کند

Answer

E2E نمی‌تواند خطاهای HTTP را تشخیص دهد

Answer

contract testing عملکرد را تحت بار اندازه می‌گیرد

Question 25

در الگوی long-running operation، وقتی `GET /operations/123` به وضعیت completed می‌رسد، پاسخ مرسوم برای هدایت کلاینت به نتیجه چیست؟

Accepted Answer

`303 See Other` با `Location` به resource نتیجه (یا `200` با لینک نتیجه در body)

Answer

`301 Moved Permanently` به resource نتیجه

Answer

`201 Created` روی خود operation

Answer

`410 Gone` چون operation تمام شده است

Question 26

می‌خواهید optimistic concurrency را برای همه `PUT`ها اجباری کنید تا هیچ کلاینتی بدون `If-Match` resource را بازنویسی نکند. پاسخ به درخواست بدون شرط چیست؟

Accepted Answer

`428 Precondition Required`

Answer

`412 Precondition Failed`

Answer

`409 Conflict`

Answer

`400 Bad Request` بدون توضیح

Question 27

Hyrum's Law درباره APIها چه می‌گوید؟

Accepted Answer

با تعداد کافی کاربر، هر رفتار قابل‌مشاهده سیستم، فارغ از قرارداد، مورد وابستگی کسی خواهد بود

Answer

هر API بعد از دو سال باید بازنویسی شود

Answer

تعداد endpointها باید با جذر تعداد کاربران متناسب باشد

Answer

latency یک API با تعداد فیلدهایش رابطه خطی دارد

Question 28

چرا HATEOAS با وجود اینکه بخشی از تعریف اصلی REST است، در APIهای عمومی کمتر پذیرفته شده است؟

Accepted Answer

اکثر کلاینت‌ها برای UI مشخص hardcode می‌شوند و از لینک‌ها کشف پویا نمی‌کنند؛ هزینه payload و tooling بیشتر از سود است

Answer

HATEOAS با JSON سازگار نیست و فقط با XML کار می‌کند

Answer

HATEOAS نیاز به HTTP/3 دارد

Answer

HATEOAS امنیت API را به‌شدت کاهش می‌دهد

Question 29

چرا `OFFSET 1000000 LIMIT 20` روی یک جدول بزرگ کند است؟

Accepted Answer

دیتابیس باید یک میلیون ردیف را پیمایش و دور بریزد تا به ۲۰ ردیف برسد

Answer

چون LIMIT کمتر از ۱۰۰ باعث full table lock می‌شود

Answer

چون OFFSET فقط روی ستون‌های رشته‌ای کار می‌کند

Answer

چون نتیجه باید قبل از ارسال gzip شود

Question 30

برگرداندن `totalCount` در هر پاسخ لیستی روی جدولی با صدها میلیون ردیف مشکل‌ساز شده است. بهترین رویکرد چیست؟

Accepted Answer

count را اختیاری (opt-in) یا تقریبی کنید و برای ناوبری به `hasNextPage` تکیه کنید

Answer

count را در هر درخواست با `SELECT COUNT(*)` دقیق ادامه دهید

Answer

pagination را حذف کنید تا count لازم نباشد

Answer

count را در کلاینت با دانلود همه ردیف‌ها حساب کنید

Question 31

cursor pagination روی `ORDER BY price` گاهی آیتم‌ها را جا می‌اندازد یا تکرار می‌کند. علت چیست؟

Accepted Answer

`price` یکتا نیست؛ باید یک tie-breaker یکتا مثل `id` به sort و cursor اضافه شود

Answer

cursorها فقط با ستون‌های تاریخ کار می‌کنند

Answer

دیتابیس باید در حالت read-uncommitted باشد

Answer

باید به جای cursor از `ORDER BY RANDOM()` استفاده کرد

Question 32

مشتریان می‌خواهند ۵۰۰٬۰۰۰ رکورد را از طریق API وارد کنند. کدام طراحی مقیاس‌پذیرتر است؟

Accepted Answer

آپلود فایل/batch به یک job غیرهمگام (`202` + resource وضعیت) با گزارش خطای per-row

Answer

یک درخواست همگام `POST` با همه رکوردها و timeout ده دقیقه‌ای

Answer

۵۰۰٬۰۰۰ درخواست `POST` جداگانه بدون هیچ محدودیتی

Answer

ارسال رکوردها از طریق query string در `GET`

Question 33

در زنجیره A→B→C، هر لایه ۳ بار retry می‌کند. وقتی C کند می‌شود چه اتفاقی می‌افتد و راه‌حل چیست؟

Accepted Answer

بار روی C تا ۲۷ برابر تقویت می‌شود؛ retry را فقط در یک لایه انجام دهید و از retry budget و circuit breaker استفاده کنید

Answer

هیچ اتفاقی نمی‌افتد چون retryها موازی‌اند

Answer

C به‌طور خودکار scale می‌شود و مشکل حل است

Answer

تعداد retry را در هر لایه به ۱۰ افزایش دهید

Question 34

کلاینت deadline دو ثانیه دارد و درخواست از سه سرویس عبور می‌کند. چرا deadline باید propagate شود؟

Accepted Answer

تا سرویس‌های downstream بعد از انصراف کلاینت کار بی‌فایده انجام ندهند و زمان باقی‌مانده را رعایت کنند

Answer

چون بدون آن TLS handshake انجام نمی‌شود

Answer

تا پاسخ‌ها در CDN cache شوند

Answer

چون protobuf بدون deadline قابل decode نیست

Question 35

یک gateway/proxy کدام درخواست‌ها را می‌تواند بعد از قطع اتصال به‌طور خودکار و امن retry کند؟

Accepted Answer

درخواست‌های با متد idempotent (`GET`، `PUT`، `DELETE`) یا درخواست‌هایی که idempotency key دارند

Answer

همه درخواست‌ها از جمله `POST` بدون کلید

Answer

فقط درخواست‌هایی که body ندارند، صرف‌نظر از متد

Answer

فقط درخواست‌های `POST` چون معمولاً مهم‌ترند

Question 36

سروری مقدار هدر `Origin` را بدون بررسی در `Access-Control-Allow-Origin` بازتاب می‌دهد و `Allow-Credentials: true` دارد. ریسک چیست؟

Accepted Answer

هر سایت مخربی می‌تواند با cookieهای کاربر درخواست بزند و پاسخ‌های حساس را بخواند

Answer

هیچ ریسکی ندارد چون مرورگر origin را تأیید کرده است

Answer

فقط باعث کند شدن preflight می‌شود

Answer

سرور دیگر قادر به خواندن cookieها نیست

Question 37

SPA روی `app.example.com` و API روی `api.example.com` است و preflightها latency قابل‌توجهی اضافه می‌کنند. یک راه‌حل معماری چیست؟

Accepted Answer

سرو کردن API از همان origin از طریق reverse proxy یا BFF (مثلاً `app.example.com/api`)

Answer

غیرفعال کردن CORS در مرورگر کاربران

Answer

تبدیل همه درخواست‌ها به `GET` با توکن در URL

Answer

استفاده از `Access-Control-Allow-Origin: *` با credentials

Question 38

کاربران با باز کردن چند tab از اپ، دیگر درخواست جدیدی نمی‌توانند بفرستند. اپ از SSE روی HTTP/1.1 استفاده می‌کند. علت محتمل؟

Accepted Answer

محدودیت حدود ۶ اتصال هم‌زمان به هر origin در HTTP/1.1؛ هر اتصال SSE یکی را اشغال می‌کند. HTTP/2 این را حل می‌کند

Answer

SSE فقط در یک tab در هر مرورگر کار می‌کند

Answer

سرور بعد از ۶ event اتصال را می‌بندد

Answer

`EventSource` همه درخواست‌های `fetch` را لغو می‌کند

Question 39

سرویس چت با WebSocket روی ۱۰ node اجرا می‌شود و کاربران یک اتاق روی nodeهای مختلف وصل‌اند. چطور پیام به همه می‌رسد؟

Accepted Answer

یک backplane pub/sub (مثل Redis Pub/Sub، NATS یا Kafka) که پیام‌ها را بین nodeها پخش کند

Answer

فقط sticky session کافی است و پیام خودبه‌خود به همه nodeها می‌رسد

Answer

load balancer پیام‌های WebSocket را بین nodeها کپی می‌کند

Answer

هر کلاینت به هر ۱۰ node هم‌زمان وصل می‌شود

Question 40

API مرورگری `WebSocket` اجازه تنظیم هدر `Authorization` را نمی‌دهد. کدام رویکرد امن‌تر است؟

Accepted Answer

گرفتن یک ticket کوتاه‌عمر یک‌بارمصرف از API و ارسال آن هنگام اتصال، همراه بررسی هدر `Origin`

Answer

قرار دادن access token بلندمدت در query string برای همیشه

Answer

اتصال بدون احراز هویت و اعتماد به IP کاربر

Answer

احراز هویت فقط یک بار در زمان ثبت‌نام کاربر

Question 41

برای ارتباط داخلی بین microserviceها با ترافیک بسیار بالا و تیم‌های polyglot، چرا gRPC اغلب انتخاب می‌شود؟

Accepted Answer

قرارداد strongly-typed با codegen در زبان‌های مختلف، serialization باینری کارآمد و streaming روی HTTP/2

Answer

چون پاسخ‌های gRPC به‌راحتی در CDN و مرورگر cache می‌شوند

Answer

چون debug کردن آن با curl ساده‌تر از REST است

Answer

چون مرورگرها به‌طور native از آن پشتیبانی می‌کنند

Question 42

کدام سناریو قوی‌ترین دلیل برای انتخاب GraphQL به جای REST است؟

Accepted Answer

چند کلاینت متنوع (وب، iOS، Android) با نیازهای داده متفاوت که داده را از چند سرویس تجمیع می‌کنند

Answer

یک API ساده برای آپلود و دانلود فایل‌های بزرگ

Answer

یک API عمومی read-heavy که به cache شدید در CDN وابسته است

Answer

ارتباط داخلی سرویس‌به‌سرویس با latency بسیار پایین

Question 43

توسعه‌دهنده‌ای برای بهبود کارایی، یک instance سراسری DataLoader بین همه requestها به اشتراک گذاشته است. مشکل جدی چیست؟

Accepted Answer

cache آن بین کاربران مشترک می‌شود؛ داده می‌تواند stale شود یا با نادیده گرفتن مجوزها به کاربر دیگر نشت کند

Answer

DataLoader سراسری batching را کاملاً غیرفعال می‌کند

Answer

Node.js اجازه ساخت object سراسری نمی‌دهد

Answer

هیچ مشکلی ندارد و روش توصیه‌شده است

Question 44

چرا برخی تیم‌ها خطاهای کسب‌وکار mutation را به‌صورت union type (مثلاً `CreateUserResult = User | EmailTaken`) مدل می‌کنند نه در آرایه `errors`؟

Accepted Answer

خطاهای مورد انتظار typed و قابل کشف در schema می‌شوند و `errors` برای خطاهای غیرمنتظره می‌ماند

Answer

چون آرایه `errors` در مشخصات GraphQL منسوخ شده است

Answer

چون union typeها پاسخ را سریع‌تر serialize می‌کنند

Answer

چون آرایه `errors` فقط روی WebSocket کار می‌کند

Question 45

مهاجم با یک درخواست GraphQL شامل ۱۰۰۰ alias از mutation `login` رمزها را brute force می‌کند و rate limit مبتنی بر درخواست را دور می‌زند. دفاع مناسب؟

Accepted Answer

محدود کردن تعداد alias/عملیات در هر درخواست و rate limit در سطح resolver یا هزینه

Answer

غیرفعال کردن HTTPS برای endpoint GraphQL

Answer

افزایش حداکثر اندازه body درخواست

Answer

تبدیل mutation `login` به query

Question 46

چرا سرور باید برای `If-Match` از ETag قوی استفاده کند نه ضعیف؟

Accepted Answer

`If-Match` مقایسه قوی دارد؛ ETag ضعیف فقط معادل معنایی است و هرگز match نمی‌شود

Answer

چون ETag ضعیف در HTTP/2 پشتیبانی نمی‌شود

Answer

چون ETag ضعیف فقط توسط CDNها تولید و فهمیده می‌شود

Answer

چون ETag قوی امضای رمزنگاری دارد

Question 47

`Cache-Control: max-age=60, stale-while-revalidate=300` چه رفتاری ایجاد می‌کند؟

Accepted Answer

تا ۶۰ ثانیه تازه است؛ تا ۵ دقیقه بعد، نسخه کهنه فوراً سرو و در پس‌زمینه revalidate می‌شود

Answer

پاسخ ۳۰۰ ثانیه cache و سپس برای ۶۰ ثانیه غیرقابل دسترس است

Answer

کلاینت باید هر ۶۰ ثانیه درخواست را همگام revalidate کند و منتظر بماند

Answer

فقط زمانی که سرور خطا بدهد نسخه کهنه استفاده می‌شود

Question 48

برای حذف نسخه v1 یک API عمومی با هزاران مصرف‌کننده، کدام فرایند حرفه‌ای‌تر است؟

Accepted Answer

اعلام با `Deprecation`/`Sunset`، رصد مصرف per-client، اطلاع‌رسانی مستقیم، brownoutهای زمان‌بندی‌شده و سپس حذف

Answer

حذف ناگهانی در یک release و پاسخ به تیکت‌های پشتیبانی

Answer

نگه داشتن v1 برای همیشه بدون هیچ اعلامی

Answer

تغییر بی‌صدای رفتار v1 به رفتار v2

Question 49

اضافه کردن مقدار جدید `REFUNDED` به enum فیلد `status` در پاسخ، چه زمانی می‌تواند breaking باشد؟

Accepted Answer

وقتی کلاینت‌ها switch کامل روی مقادیر شناخته‌شده دارند یا مقدار ناشناخته را خطا می‌دانند

Answer

هرگز؛ اضافه کردن مقدار enum همیشه امن است

Answer

فقط اگر نام مقدار با حرف بزرگ نوشته شده باشد

Answer

فقط وقتی API روی HTTP/1.1 سرو شود

Question 50

چرا `PATCH` طبق مشخصات idempotent تضمین نشده است؟

Accepted Answer

چون برخی عملیات patch مثل JSON Patch `add` با مسیر `/items/-` (افزودن به انتهای آرایه) در هر تکرار اثر جدید دارند

Answer

چون `PATCH` همیشه یک resource جدید می‌سازد

Answer

چون `PATCH` نمی‌تواند body داشته باشد

Answer

چون `PATCH` یک متد safe است