آموزش ۵۰۰+ سوال و جواب مصاحبه REST API سال ۲۰۲۶ - آخرین آپدیت

پوشش دقیق حوزه‌های آزمون

این مجموعه آزمون‌های تمرینی جامع برای ارزیابی دقیق و تقویت دانش شما در حوزه‌های اصلی که در مراحل غربالگری فنی نقش‌های مهندسی بررسی می‌شوند، طراحی شده است.

• پروتکل‌های HTTP (۲۰%): کالبدشکافی متدهای اصلی HTTP (GET, POST, PUT, DELETE, PATCH)، بررسی افعال ایمن در مقابل غیرایمن، مدیریت هدرها و جزئیات پروتکل.

• معماری REST (۱۸%): محدودیت‌های معماری اصلی شامل بدون وضعیت بودن (Statelessness)، جداسازی کلاینت-سرور، شناسایی منابع از طریق URIهای ساختاریافته و نگاشت دقیق کدهای وضعیت HTTP.

• طراحی API (۱۵%): طراحی نقاط انتهایی پیش‌بینی‌پذیر، فرمت‌های بدنه (JSON, XML)، ساختارهای قدرتمند برای مدیریت خطا، استراتژی‌های نسخه‌بندی (URI, Header, Query string) و مکانیسم‌های صفحه‌بندی.

• امنیت و احراز هویت (۱۲%): پیاده‌سازی جریان‌های OAuth، امضا و تایید توکن‌های JSON Web Tokens (JWT)، مکانیسم‌های رمزنگاری SSL/TLS، اعتبارسنجی ورودی‌ها و استراتژی‌های دفاعی احراز هویت API.

• مفاهیم پیشرفته REST (۱۰%): هایپرمدیا (HATEOAS)، تضمین‌های Idempotency، الگوریتم‌های Rate limiting، استراتژی‌های کشینگ چندسطحی و مذاکره محتوا.

• مقایسه با سایر APIها (۸%): ارزیابی‌های ساختاری معماری در مقایسه SOAP در برابر REST، GraphQL در برابر REST و اصول طراحی متمایز در سرویس‌های وب RESTful.

• عیب‌یابی و بهترین روش‌ها (۷%): تکنیک‌های عملی دیباگ، استراتژی‌های استاندارد مدیریت خطا، بهینه‌سازی عملکرد، مستندسازی ساختاری API و متدولوژی‌های تست.

• ابزارها و تکنولوژی‌ها (۱۰%): بهره‌گیری از مشخصات Swagger و OpenAPI، کار با اکوسیستم‌های JAX-RS، پیکربندی API Gatewayها و مدیریت پلتفرم‌های مدیریت API سازمانی.

درباره دوره

پیمودن مسیر مصاحبه‌های طراحی سیستم مدرن و مهندسی بک‌اند نیازمند درک عمیق و در سطح عملیاتی از چرخه حیات API است. دستیابی به جایگاهی مانند توسعه‌دهنده API، مهندس Full Stack یا معمار نرم‌افزار به توانایی شما در مدیریت موارد خاص دنیای واقعی بستگی دارد؛ مانند انتخاب بین PUT و PATCH، جلوگیری از دستکاری توکن‌ها، مدیریت Race Conditions از طریق هدرهای HTTP یا طراحی استراتژی‌های بهینه برای محدودسازی نرخ.

من این مخزن گسترده شامل ۵۵۰ سوال تمرینی بسیار تخصصی و اورجینال را طراحی کرده‌ام تا به شما کمک کنم بر سناریوهایی که پنل‌های فنی ارزیابی می‌کنند، مسلط شوید. این بانک سوالات به جای تعاریف ابتدایی، مستقیماً به سراغ توازن‌های معماری، پیامدهای امنیتی و حالت‌های خطا می‌رود. هر سوال با یک تحلیل دقیق و گام‌به‌گام پشتیبانی شده است که توضیح می‌دهد چرا گزینه صحیح با استانداردهای معماری مطابقت دارد و چرا گزینه‌های جایگزین باعث ایجاد باگ، افت عملکرد یا نقص امنیتی در محیط واقعی می‌شوند. استفاده از این ارزیابی‌های سناریومحور واقع‌گرایانه تضمین می‌کند که با اعتماد به نفس کامل وارد مصاحبه شوید و در اولین تلاش، مراحل غربالگری فنی را پشت سر بگذارید.

نمونه سوالات تمرینی

برای بررسی عمق، ساختار و کیفیت توضیحات ارائه شده در این بانک جامع، این سه نمونه سوال در سطح عملیاتی را مرور کنید.

سوال ۱: واقعیت‌های Idempotency در اجرای متدهای HTTP

یک مهندس باید مجموعه‌ای از Endpoints را برای یک پلتفرم تجارت الکترونیک طراحی کند. هنگام ارزیابی رفتارهای تکرار شبکه (Retry)، او باید تضمین کند که درخواست‌های تکراری کلاینت باعث ایجاد اثرات جانبی غیرمنتظره در وضعیت سیستم نشود. کدام یک از موارد زیر به درستی تضمین‌های Idempotency متدهای استاندارد HTTP را توصیف می‌کند؟

• الف) POST و PUT ذاتاً Idempotent هستند، در حالی که PATCH و DELETE اکیداً غیر Idempotent می‌باشند.

• ب) متدهای GET، PUT و DELETE از نوع Idempotent هستند، در حالی که POST ذاتاً غیر Idempotent است.

• ج) تمام متدهای استاندارد HTTP تا زمانی که دیتابیس بک‌اند تراکنش‌ها را درست مدیریت کند، کاملاً Idempotent هستند.

• د) فقط درخواست‌های GET و HEAD از نوع Idempotent هستند زیرا اصلاً وضعیت سرور را تغییر نمی‌دهند.

• هـ) PUT کاملاً غیر Idempotent است زیرا هر بار که اجرا شود، یک نمایش جدید از موجودیت ایجاد می‌کند.

• و) DELETE غیر Idempotent است زیرا اجرای مجدد آن روی منبعی که وجود ندارد، به جای ۲۰۰ کد ۴۰۴ برمی‌گرداند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل correctness: طبق استانداردهای مشخصات HTTP، یک عملیات Idempotent می‌تواند چندین بار اجرا شود بدون اینکه وضعیت نهایی سرور را فراتر از درخواست اول تغییر دهد. GET ایمن و Idempotent است زیرا فقط داده‌ها را بازیابی می‌کند. PUT منبع هدف را به طور کامل جایگزین می‌کند، به این معنی که چندین درخواست PUT یکسان منجر به وضعیت یکسانی از منبع می‌شود. DELETE نیز Idempotent است زیرا پس از حذف یک منبع، عملیات‌های حذف بعدی سیستم را در همان وضعیت «حذف شده» نگه می‌دارند، صرف‌نظر از تغییر در کد پاسخی که برمی‌گردد. POST صریحاً غیر Idempotent است زیرا اجراهای متعدد باعث ایجاد منابع تکراری می‌شود.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: POST Idempotent نیست و DELETE Idempotent است.

  • گزینه ج نادرست است: مشخصات HTTP ویژگی‌های متد را تعیین می‌کند، نه منطق لایه دیتابیس.

  • گزینه د نادرست است: GET و HEAD متدهای ایمن هستند، اما PUT و DELETE نیز اکیداً Idempotent هستند حتی اگر وضعیت را تغییر دهند.

  • گزینه هـ نادرست است: PUT منبع را در یک URI خاص به‌روزرسانی یا جایگزین می‌کند و وضعیت نهایی آن در تکرارها پیش‌بینی‌پذیر است.

  • گزینه و نادرست است: تغییر در کد وضعیت بازگشتی (200 OK در برابر 404 Not Found) Idempotency را از بین نمی‌برد؛ آنچه اهمیت دارد این است که وضعیت سرور بک‌اند پس از اولین حذف، یکسان باقی بماند.

سوال ۲: طراحی استراتژی‌های نسخه‌بندی (Versioning) مناسب برای کلاینت‌های سازمانی

یک تیم باید یک API فعال در محیط عملیاتی را به دلیل تغییرات ساختاری در بدنه پاسخ (Payload)، از نسخه ۱ به نسخه ۲ منتقل کند. معمار سیستم می‌خواهد رویکردی برای نسخه‌بندی پیاده کند که باعث شکست ادغام‌های موجود کلاینت‌ها نشود، از مکانیسم‌های کشینگ مرورگر به صورت پیش‌فرض پشتیبانی کند و URIهای منابع را تمیز نگه دارد. کدام استراتژی با این نیازها سازگارتر است؟

• الف) استفاده انحصاری از نسخه‌بندی مسیر URI با افزودن پیشوند /v1/ و /v2/ به تمام نقاط انتهایی.

• ب) استفاده از نسخه‌بندی هدر سفارشی (Custom Header) با الزام کلاینت‌ها به ارسال کلید X-API-Version در درخواست‌ها.

• ج) استفاده از مذاکره محتوا (Content Negotiation) از طریق هدر استاندارد Accept برای تعریف شمای Payload.

• د) تکثیر کل زیرساخت سرور برای اجرای نسخه جدید API روی یک ساب‌دومین مجزا.

• هـ) اجتناب از نسخه‌بندی صریح و نوشتن دستورات شرطی پیچیده در داخل یک بلوک کد کنترلر واحد.

• و) پیاده‌سازی نسخه‌بندی رشته پرس‌وجو (Query String) با افزودن پارامتر نسخه به انتهای هر URL.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل correctness: نسخه‌بندی از طریق مذاکره محتوا از هدر استاندارد Accept استفاده می‌کند (مثلاً Accept: application/vnd.company.v2+json). این کار باعث می‌شود URI منبع کاملاً تمیز و ثابت بماند که با اصول واقعی REST مطابقت دارد. همچنین با استفاده از هدر پاسخ Vary: Accept برای تشخیص تمیز شمای کش شده، از موتورهای کشینگ استاندارد HTTP پشتیبانی می‌کند.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: نسخه‌بندی مسیر URI باعث تغییر URL می‌شود، به این معنی که یک منبع مفهومی یکسان دارای دو شناسه متفاوت است که این امر اصول REST را نقض کرده و استراتژی‌های کشینگ بلندمدت را پیچیده می‌کند.

  • گزینه ب نادرست است: هدرهای سفارشی جزئیات نسخه را از URL مخفی می‌کنند، اما کشینگ استاندارد پروکسی را مختل می‌کنند زیرا اکثر پروکسی‌های اینترنتی نسخه‌های مختلف را بر اساس هدرهای سفارشی کش نمی‌کنند.

  • گزینه د نادرست است: تقسیم محیط‌های زیرساختی باعث ایجاد سربار عملیاتی گسترده می‌شود و قوانین کشینگ لایه اپلیکیشن را حل نمی‌کند.

  • گزینه هـ نادرست است: حذف قوانین نسخه‌بندی و اتکا به بلوک‌های شرطی داخلی، قابلیت نگهداری کد را کاهش داده و باعث ایجاد بدهی فنی (Technical Debt) شدید می‌شود.

  • گزینه و نادرست است: نسخه‌بندی رشته پرس‌وجو الگوهای تمیز URI را به خطر می‌اندازد و اغلب با آرایه‌های فیلتر یا مرتب‌سازی سفارشی تداخل دارد.

سوال ۳: مدیریت خطاهای اعتبارسنجی توکن در لایه API Gateway

یک API Gateway درخواستی را دریافت می‌کند که حاوی یک توکن JSON Web Token (JWT) منقضی شده در هدر Authorization است. لایه Gateway باید پردازش را فوراً متوقف کند تا از رسیدن درخواست به میکروسرویس‌های پایین‌دست جلوگیری کند. طبق اصول طراحی معماری REST، مناسب‌ترین پاسخ بدنه HTTP چیست؟

• الف) بازگرداندن کد وضعیت 400 Bad Request همراه با یک رشته متنی ساده که انقضای توکن را توصیف می‌کند.

• ب) بازگرداندن کد وضعیت 401 Unauthorized همراه با هدر چالش WWW-Authenticate که جزئیات خطا را بیان می‌کند.

• ج) بازگرداندن کد وضعیت 403 Forbidden زیرا هویت کاربر در داخل بدنه توکن منقضی شده شناسایی شده است.

• د) بازگرداندن کد وضعیت 500 Internal Server Error زیرا اعتبارسنجی در منطق هسته سیستم Gateway شکست خورد.

• هـ) بازگرداندن کد وضعیت 404 Not Found برای مخفی کردن ساختار امنیتی از عوامل مخرب احتمالی.

• و) بازگرداندن کد وضعیت 200 OK با یک پارامتر کد خطای داخلی سفارشی در بدنه JSON.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل correctness: پاسخ 401 Unauthorized دقیقاً برای سناریوهایی در نظر گرفته شده است که احراز هویت وجود ندارد، نامعتبر است یا منقضی شده است. مشخصات HTTP همچنین بیان می‌کند که پاسخ 401 باید شامل هدر WWW-Authenticate باشد تا به کلاینت آموزش دهد چگونه به درستی احراز هویت کند یا توکن‌های خود را نوسازی (Refresh) نماید.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: 400 Bad Request نشان‌دهنده نحو (Syntax) نادرست درخواست است، نه شکست در اعتبارنامه (Credentials).

  • گزینه ج نادرست است: 403 Forbidden به این معنی است که سرور می‌داند کاربر کیست، اما کاربر احراز هویت شده صریحاً فاقد حقوق دسترسی برای آن منبع خاص است.

  • گزینه د نادرست است: 500 Internal Server Error به معنای یک باگ در سمت سرور یا کرش سیستم است، در حالی که انقضای توکن یک نتیجه مورد انتظار از اعتبارسنجی است.

  • گزینه هـ نادرست است: استفاده از 404 برای مخفی کردن نقاط انتهایی، دیباگ کلاینت را پیچیده کرده و پیش‌بینی‌پذیری رابط API را کاهش می‌دهد.

  • گزینه و نادرست است: بازگرداندن 200 OK برای شکست در احراز هویت، قوانین اصلی نگاشت کدهای وضعیت HTTP را نقض کرده و منطق Interceptorهای سمت کلاینت را مختل می‌کند.

آنچه در انتظار شماست

• به آزمون‌های سوالات مصاحبه خوش آمدید تا شما را برای موفقیت در آزمون تمرینی REST API آماده کنیم.

• شما می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات گسترده و اورجینال است.

• در صورت داشتن هرگونه سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح جامع و دقیق است.

• کاملاً سازگار با موبایل و اپلیکیشن Udemy.

امیدوارم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.