Headers (Content-Type, Accept, Authorization, …)

مفاهیم

Header چیست؟

Header بخشی از HTTP Request یا HTTP Response است که اطلاعات کنترلی و متادیتای ارتباط را حمل می‌کند.
یعنی Header معمولاً خود داده‌ی اصلی بیزینسی نیست، بلکه اطلاعاتی درباره‌ی نوع داده، نحوه پردازش، احراز هویت، کش، زبان یا سایر تنظیمات ارتباط را مشخص می‌کند.

در تست API، تحلیل Header خیلی مهم است چون رفتار درست API فقط به Body وابسته نیست؛ ممکن است نتیجه‌ی API با تغییر Header کاملاً عوض شود.

Header در Request و Response چه فرقی دارد؟

• در Request Header، Client به Server می‌گوید درخواست را چگونه پردازش کند یا چه اطلاعاتی همراه درخواست است.

• در Response Header، Server به Client می‌گوید پاسخ چه ویژگی‌هایی دارد، چگونه تفسیر شود، قابل Cache هست یا نه، چه نوع محتوایی دارد و موارد مشابه.

Headerهای مهم در تست API

Content-Type چیست؟

Content-Type مشخص می‌کند محتوای Body از چه نوعی است.
یعنی Server یا Client با دیدن Content-Type می‌فهمد داده‌ی داخل Body را با چه فرمتی باید تفسیر کند.

نمونه‌های رایج:

• application/json

• application/xml

• application/x-www-form-urlencoded

• multipart/form-data

• text/plain

کاربرد Content-Type در Request

وقتی Client در POST / PUT / PATCH داده می‌فرستد، معمولاً باید مشخص کند بدنه‌ی درخواست چه فرمتی دارد.
مثلاً اگر Body به‌صورت JSON باشد، باید این Header را بفرستد:

Content-Type: application/json

اگر این Header اشتباه باشد، Server ممکن است:

• Body را درست Parse نکند

• 400 Bad Request بدهد

• 415 Unsupported Media Type بدهد

• یا حتی داده را اشتباه پردازش کند

کاربرد Content-Type در Response

Server هم در پاسخ با Content-Type مشخص می‌کند Response Body از چه نوعی است.
مثلاً اگر پاسخ JSON باشد:

Content-Type: application/json

تستر باید بررسی کند Content-Type پاسخ با چیزی که Contract گفته هم‌خوانی دارد.

Accept چیست؟

Accept هدر درخواست است و به Server می‌گوید Client انتظار دارد پاسخ را با چه فرمتی دریافت کند.
مثلاً:

Accept: application/json

یعنی Client می‌گوید: «من انتظار دارم پاسخ را به‌صورت JSON بگیرم.»

تفاوت Accept و Content-Type

این یکی از مهم‌ترین نکات مفهومی است:

• Content-Type → نوع داده‌ای که الان در Body وجود دارد

• Accept → نوع داده‌ای که Client دوست دارد در Response دریافت کند

پس:

• در Request، Content-Type درباره‌ی بدنه‌ی ارسالی است

• Accept درباره‌ی فرمت پاسخ مورد انتظار است

مثال ساده برای تفاوت Content-Type و Accept

فرض کن Client این Request را می‌فرستد:

POST /customers
Content-Type: application/json
Accept: application/json

معنی‌اش:

• من Body را به‌صورت JSON می‌فرستم

• انتظار دارم Response را هم به‌صورت JSON بگیرم

Authorization چیست؟

Authorization برای ارسال اطلاعات احراز هویت/مجوز به Server استفاده می‌شود.
در تست API این Header خیلی مهم است چون خیلی از Endpointها بدون آن نباید قابل استفاده باشند.

رایج‌ترین حالت‌ها:

Bearer Token

Authorization: Bearer eyJ...

در این حالت Client یک Access Token را همراه درخواست می‌فرستد و Server بر اساس آن هویت و سطح دسترسی را بررسی می‌کند.

Basic Auth

Authorization: Basic <base64-credentials>

در این مدل نام کاربری و رمز عبور به‌صورت Base64 ارسال می‌شود.
در سیستم‌های مدرن کمتر از Basic Auth برای APIهای حساس استفاده می‌شود، ولی باید مفهومش را بلد باشیم.

چرا Authorization Header برای تستر مهم است؟

چون تستر باید بتواند سناریوهای زیر را بررسی کند:

• بدون Authorization درخواست بفرستد

• با Token نامعتبر درخواست بفرستد

• با Token کاربر اشتباه درخواست بفرستد

• با کاربری که Permission ندارد عملیات انجام دهد

و بررسی کند که API:

• 401 Unauthorized می‌دهد یا نه

• 403 Forbidden را درست برمی‌گرداند یا نه

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

Headerهای مهم دیگر که باید بشناسی

Accept-Language

زبان مورد انتظار Client را مشخص می‌کند.
مثلاً:

Accept-Language: fa-IR

در APIهایی که پیام‌ها یا محتوا چندزبانه‌اند مهم است.

User-Agent

مشخص می‌کند درخواست از چه Client یا ابزاری آمده است.
مثلاً مرورگر، اپ موبایل یا Postman.
در تست معمولاً کمتر محور اصلی سؤال است، ولی در Logging، Tracing یا تحلیل رفتار Client می‌تواند مهم باشد.

Cache-Control

برای کنترل Caching استفاده می‌شود.
مثلاً Server می‌تواند بگوید این پاسخ قابل کش شدن هست یا نه.

نمونه:

Cache-Control: no-cache

یا:

Cache-Control: max-age=3600

Cookie

برای نگه‌داری Session یا اطلاعات خاص Client استفاده می‌شود.
در بعضی سیستم‌ها به‌جای Bearer Token، احراز هویت یا نگه‌داری وضعیت از طریق Cookie انجام می‌شود.

Host

نام دامنه مقصد را مشخص می‌کند.
در سطح تست روزمره کمتر محور اصلی است، ولی بخشی از ساختار Request استاندارد HTTP است.

Correlation-ID / Trace-ID

برای ردیابی یک Request در لاگ‌ها و بین سرویس‌ها استفاده می‌شود.
در سیستم‌های بانکی و Microserviceها خیلی مهم است چون به تستر کمک می‌کند مسیر یک درخواست را در Logها پیدا کند.

نمونه:

X-Correlation-ID: 12345-abc

خطاهای رایج مرتبط با Header

1) نبودن Content-Type

اگر Body داشته باشیم ولی Content-Type ندهیم، ممکن است Server نتواند داده را درست Parse کند.

2) Content-Type اشتباه

مثلاً Body واقعاً JSON است ولی Content-Type: text/plain فرستاده‌ایم.
در این حالت رفتار API باید قابل پیش‌بینی باشد و معمولاً انتظار 4xx داریم.

3) Accept ناسازگار

اگر Client فرمتی بخواهد که API پشتیبانی نمی‌کند، ممکن است خطا برگردد یا API نتواند پاسخ درست بدهد.

4) Authorization اشتباه یا ناقص

مثل:

• نبودن Token

• Token منقضی

• Token کاربر بدون دسترسی

• استفاده از فرمت اشتباه Header

5) لو رفتن اطلاعات حساس در Header

گاهی Token یا اطلاعات حساس در لاگ‌ها یا ابزارها ثبت می‌شوند.
تستر باید حواسش به Security و Confidential Data Exposure هم باشد.

تست‌هایی که روی Header باید در ذهن داشته باشی

برای Content-Type

• اگر application/json لازم است، با Content-Type اشتباه چه می‌شود؟

• اگر Body خالی است ولی Content-Type داریم چه رفتاری می‌بینیم؟

• اگر JSON خراب باشد ولی Content-Type درست باشد چه می‌شود؟

برای Accept

• اگر Accept: application/json بفرستیم پاسخ JSON می‌آید؟

• اگر Accept را حذف کنیم چه می‌شود؟

• اگر فرمت پشتیبانی‌نشده بخواهیم چه رفتاری داریم؟

برای Authorization

• بدون Token

• با Token اشتباه

• با Token منقضی

• با Token کاربر بدون Permission

• با Token معتبر و دسترسی درست

برای Correlation-ID / Trace-ID

• آیا در Request می‌توان مقدار را فرستاد؟

• آیا در لاگ‌ها قابل ردیابی است؟

• آیا در پاسخ یا زنجیره‌ی سرویس‌ها حفظ می‌شود؟

نگاه تستری به Headers

تستر باید Header را فقط یک «فیلد اضافی» نبیند. Header بخشی از Contract است.
یعنی اگر Swagger گفته:

• Authorization اجباری است

• Content-Type باید application/json باشد

• Accept باید JSON باشد

این‌ها همگی جزو رفتار قابل تست‌اند و Failure در آن‌ها می‌تواند Defect محسوب شود.

نکات امتحانی مهم Headers

• Header متادیتا و اطلاعات کنترلی Request/Response را حمل می‌کند.

• Content-Type با Accept فرق دارد:

  • Content-Type = نوع محتوای داخل Body

  • Accept = نوع پاسخ مورد انتظار Client

• Authorization برای احراز هویت/مجوز استفاده می‌شود و مستقیم به 401 و 403 وصل است.

• Content-Type اشتباه می‌تواند باعث 400 یا 415 شود.

• Trace-ID / Correlation-ID برای Log analysis و RCA خیلی مهم‌اند.

• Headerها بخشی از API Contract هستند و باید در تست بررسی شوند، نه اینکه فقط Body را چک کنیم.

نمونه پاسخ کوتاه

Headers بخش کنترلی و متادیتای HTTP Request/Response هستند و اطلاعاتی مثل نوع داده، فرمت پاسخ مورد انتظار، احراز هویت، کش و ردیابی درخواست را مشخص می‌کنند. از مهم‌ترین Headerها می‌توان به Content-Type، Accept و Authorization اشاره کرد. Content-Type نوع محتوای Body را مشخص می‌کند، Accept فرمت پاسخ مورد انتظار Client را نشان می‌دهد و Authorization برای ارسال اطلاعات احراز هویت یا Token استفاده می‌شود. در تست API، بررسی درست Headerها برای تحلیل Contract، Validation، Authentication و Response behavior ضروری است.

کلیدواژه‌ها

Headers | Request Header | Response Header | Content-Type | Accept | Authorization | Bearer Token | Basic Auth | Authentication | Authorization / Permission | Accept-Language | User-Agent | Cache-Control | Cookie | Host | Trace-ID | Correlation-ID | application/json | application/xml | multipart/form-data | application/x-www-form-urlencoded | 415 Unsupported Media Type | 401 Unauthorized | 403 Forbidden | Contract

توضیح و کاربرد کلیدواژه‌ها

Headers (اطلاعات کنترلی و متادیتای Request/Response): برای مشخص کردن نوع داده، احراز هویت، زبان، کش، ردیابی و سایر تنظیمات ارتباط در API استفاده می‌شوند.

Request Header (Headerهای ارسالی از Client به Server): برای کنترل نحوه پردازش Request، تعیین نوع Body، ارسال Token و مشخص کردن انتظار Client از Response استفاده می‌شود.

Response Header (Headerهای ارسالی از Server به Client): برای اعلام نوع پاسخ، سیاست Cache، Cookie، اطلاعات امنیتی و متادیتای Response استفاده می‌شود.

Content-Type (نوع محتوای داخل Body): برای مشخص کردن فرمت داده‌ی ارسالی یا دریافتی مثل JSON، XML یا form-data استفاده می‌شود.

Accept (فرمت پاسخ مورد انتظار Client): برای اعلام این‌که Client ترجیح می‌دهد پاسخ را با چه نوع محتوایی دریافت کند استفاده می‌شود.

Authorization (Header حاوی اطلاعات احراز هویت یا مجوز): برای ارسال Token، Basic Auth یا سایر اطلاعات امنیتی به Server استفاده می‌شود.

Bearer Token (توکن دسترسی در Authorization Header): برای احراز هویت و دسترسی در APIهای مبتنی بر Token استفاده می‌شود.

Basic Auth (ارسال نام کاربری و رمز عبور در قالب Basic Authorization): برای احراز هویت ساده در بعضی APIها یا محیط‌های تست استفاده می‌شود.

Authentication (احراز هویت کاربر یا سیستم): در تحلیل سناریوهای 401 Unauthorized، Token و Login Flow کاربرد دارد.

Authorization / Permission (کنترل سطح دسترسی پس از احراز هویت): در تحلیل 403 Forbidden و سناریوهای مجوز دسترسی استفاده می‌شود.

Accept-Language (زبان مورد انتظار Client برای پاسخ): در APIهای چندزبانه یا بررسی پیام‌های ترجمه‌شده استفاده می‌شود.

User-Agent (شناسه Client یا ابزار ارسال‌کننده Request): در تحلیل لاگ، رفتار Client و گاهی کنترل دسترسی یا دیباگ کاربرد دارد.

Cache-Control (Header کنترل سیاست Cache): برای تعیین کش شدن یا نشدن Response و مدت اعتبار Cache استفاده می‌شود.

Cookie (داده ذخیره‌شده سمت Client که در Request/Response مبادله می‌شود): برای Session Management، احراز هویت یا نگه‌داری وضعیت Client استفاده می‌شود.

Host (دامنه یا مقصد اصلی Request): بخشی از ساختار استاندارد Request در HTTP است و در مسیردهی درخواست نقش دارد.

Trace-ID (شناسه ردیابی یک درخواست در سیستم‌های توزیع‌شده): برای دنبال کردن Request بین سرویس‌ها و تحلیل لاگ‌ها استفاده می‌شود.

Correlation-ID (شناسه همبستگی برای ردیابی یک سناریوی کامل بین چند سرویس): در RCA، Distributed Logging و تحلیل خطاهای بین‌سیستمی کاربرد دارد.

application/json (نوع محتوای JSON): رایج‌ترین Content-Type در APIهای REST برای ارسال و دریافت داده ساختاریافته است.

application/xml (نوع محتوای XML): در بعضی APIهای قدیمی‌تر یا سازمانی برای تبادل داده استفاده می‌شود.

multipart/form-data (نوع محتوای مناسب برای ارسال فایل و فرم‌های چندبخشی): برای آپلود فایل، تصویر و داده‌های فرم همراه فایل استفاده می‌شود.

application/x-www-form-urlencoded (نوع محتوای فرم URL-encoded): برای ارسال فرم‌های ساده یا بعضی سناریوهای OAuth / Login استفاده می‌شود.

415 Unsupported Media Type (فرمت محتوای ارسالی توسط API پشتیبانی نمی‌شود): وقتی Content-Type اشتباه یا نامعتبر باشد دیده می‌شود.

401 Unauthorized (احراز هویت نامعتبر یا انجام‌نشده): برای نبودن Token، Token اشتباه یا Credential نامعتبر استفاده می‌شود.

403 Forbidden (کاربر احراز هویت شده ولی مجاز به عملیات نیست): برای خطاهای سطح دسترسی و Permission استفاده می‌شود.

Contract (توافق بین Client و Server درباره رفتار API): برای بررسی این‌که کدام Headerها اجباری‌اند، چه نوع داده‌ای باید ارسال شود و API چه رفتاری باید داشته باشد استفاده می‌شود.

عالیه. از این به بعد دقیقاً با همین دو مود می‌ریم جلو:

1. «جمع‌بندی سرفصل X» → من خروجی تمیز با همان فرمت جمع‌بندی سرفصل می‌دهم.

2. «سوالات آزمونی سرفصل X» → من بر اساس سبک همین آزمون‌هایی که فرستادی، سوال مرحله‌ای و تحلیلی می‌دهم، تو جواب می‌دهی، من مثل ارزیاب نمره می‌دهم، ضعف پاسخ را می‌گویم، بعد نسخه‌ی جواب نمره‌کامل را می‌دهم.

الان می‌رویم سراغ:

سوالات آزمونی سرفصل Headers (Content-Type, Accept, Authorization, …)

من این سرفصل را هم به سبک آزمون شما می‌برم جلو:
ترکیبی از تعریف مفهومی + تحلیل تست + سناریوی API + Failure/Defect + نگاه امنیتی/سیستمی.

سوال ۱ — سطح پایه رو به متوسط

فرض کن یک API برای ایجاد مشتری داریم:

POST /customers

Request:

POST /customers
Content-Type: application/json
Accept: application/json
Authorization: Bearer valid-token

Body:

{
  "firstName": "Ali",
  "lastName": "Ahmadi",
  "nationalCode": "1234567890"
}

این API طبق Contract فقط JSON قبول می‌کند و فقط در صورت داشتن توکن معتبر اجازه ثبت مشتری می‌دهد.

سوال:

1)

به زبان ساده ولی دقیق بگو Header چیست و در این سناریو Content-Type، Accept و Authorization هر کدام چه نقشی دارند؟

2)

اگر Content-Type اشتباه ارسال شود، مثلاً:

Content-Type: text/plain

ولی Body همچنان JSON باشد، از نگاه تست API چه اتفاقی ممکن است بیفتد و چه چیزهایی را باید بررسی کنیم؟

3)

اگر Authorization اصلاً ارسال نشود ولی API همچنان 201 Created برگرداند، این را از زنجیره‌ی Failure / Defect / Error چطور تحلیل می‌کنی؟

4)

برای همین Endpoint، ۴ تست‌کیس مهم درباره Headerها طراحی کن؛ حداقل یکی مثبت و چندتا منفی.

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

مثل قبل بهتره جواب را شماره‌گذاری‌شده بدهی:

1- تعریف Header + نقش سه هدر
2- تحلیل سناریوی Content-Type اشتباه
3- تحلیل Failure / Defect / Error
4- چهار تست‌کیس هدرمحور

راهنمایی خیلی کوتاه برای اینکه نمره‌ات بالا برود

توی جوابت اگر این کلیدواژه‌ها طبیعی بیاید، امتیاز پاسخ می‌رود بالا:

• metadata of request/response

• Content negotiation

• media type

• authentication token

• authorization / access control

• server-side validation

• 415 Unsupported Media Type

• 401 Unauthorized

• 403 Forbidden

• contract

• security risk

• header validation

• negative testing

نسخه‌ی نمره‌کامل همین پاسخ — مدل جواب آزمونی

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

پاسخ نمره‌کامل — سوال ۱ سرفصل Headers

1) Header چیست و نقش Content-Type / Accept / Authorization چیست؟

Header بخشی از HTTP Request/Response است که metadata و اطلاعات کنترلی ارتباط را حمل می‌کند و معمولاً خود داده‌ی اصلی بیزینسی نیست. Header مشخص می‌کند درخواست یا پاسخ با چه قواعدی پردازش شود؛ مثل نوع داده، فرمت قابل‌قبول، احراز هویت، کش، زبان و سایر تنظیمات پروتکل.

در این سناریو:

• Content-Type: application/json
  مشخص می‌کند فرمت Request Body از نوع JSON است. Server با توجه به این Header تصمیم می‌گیرد body را با چه media type و parserای پردازش کند.

• Accept: application/json
  مشخص می‌کند Client ترجیح می‌دهد Response را با فرمت JSON دریافت کند. این Header در content negotiation نقش دارد.

• Authorization: Bearer valid-token
  برای authentication / access control استفاده می‌شود و نشان می‌دهد Client یک Bearer Token برای دسترسی به API ارسال کرده است. Server باید اعتبار توکن را بررسی کند و فقط در صورت معتبر بودن اجازه ثبت مشتری را بدهد.

2) اگر Content-Type اشتباه باشد ولی Body همچنان JSON باشد چه باید بررسی شود؟

اگر API طبق Contract فقط JSON قبول کند ولی درخواست با

Content-Type: text/plain

ارسال شود، این یک Contract mismatch است، چون Header اعلام می‌کند payload از نوع text/plain است ولی body عملاً JSON است.

در این حالت چند رفتار ممکن است رخ دهد:

1. رفتار صحیح و استاندارد:
   API باید درخواست را رد کند و 415 Unsupported Media Type برگرداند، چون media type ارسالی با Contract سازگار نیست.

2. رفتار ضعیف یا defect:
   API ممکن است Header را نادیده بگیرد و چون body قابل parse به JSON است، درخواست را بپذیرد. این حالت نشان‌دهنده ضعف در header validation یا contract enforcement است.

3. رفتار دیگر:
   ممکن است API نتواند body را با توجه به Content-Type اشتباه parse کند و 400 Bad Request برگرداند.

در تست API باید این موارد بررسی شود:

• آیا Status Code مطابق Contract است؟ ترجیحاً 415

• آیا پیام خطا درست و معنادار است؟

• آیا customer ساخته نشده و عملیات بیزینسی انجام نشده؟

• آیا Swagger / OpenAPI Contract همین رفتار را انتظار دارد؟

• آیا Server-side validation روی Header اعمال می‌شود یا API فقط body را parse می‌کند؟

3) اگر Authorization ارسال نشود ولی API همچنان 201 Created برگرداند، تحلیل Failure / Defect / Error چیست؟

اگر Authorization ارسال نشود ولی API همچنان 201 Created برگرداند، این یعنی نتیجه مشاهده‌شده با نتیجه مورد انتظار برابر نیست؛ پس در زمان اجرا یک Failure رخ داده است.

تحلیل زنجیره به این شکل است:

• Failure:
  API بدون احراز هویت معتبر، مشتری را ایجاد کرده و 201 Created داده است.

• Defect:
  احتمالاً authorization/authentication check در API به‌درستی پیاده‌سازی نشده، bypass شده یا روی این endpoint اعمال نشده است.

• Error:
  ممکن است توسعه‌دهنده، طراح یا تیم در تحلیل Requirement امنیتی یا پیاده‌سازی کنترل دسترسی دچار اشتباه شده باشند.

نکته مهم:

در این سناریو چون Authorization اصلاً ارسال نشده، پاسخ درست معمولاً 401 Unauthorized است، نه 201 Created.
این وضعیت یک Security Risk جدی است چون API بدون احراز هویت اجازه ایجاد داده می‌دهد.

4) چهار تست‌کیس مهم برای Headerها

TC1 — Positive

Scenario: ارسال درخواست با Headerهای صحیح

POST /customers
Content-Type: application/json
Accept: application/json
Authorization: Bearer valid-token

Expected Result:

• Status Code = 201 Created

• مشتری با موفقیت ساخته شود

• Response با فرمت JSON برگردد

TC2 — Negative / Content-Type mismatch

Scenario:
Content-Type: text/plain ولی body همچنان JSON باشد.

Expected Result:

• Status Code = 415 Unsupported Media Type یا طبق Contract

• درخواست reject شود

• مشتری ساخته نشود

TC3 — Negative / Missing Authorization

Scenario:
Header Authorization ارسال نشود.

Expected Result:

• Status Code = 401 Unauthorized

• عملیات ثبت مشتری انجام نشود

• پیام خطای مرتبط با احراز هویت برگردد

TC4 — Negative / Invalid Authorization token

Scenario:
Header ارسال شود ولی توکن نامعتبر یا malformed باشد:

Authorization: Bearer invalid-token

Expected Result:

• Status Code = 401 Unauthorized

• درخواست رد شود

• مشتری ساخته نشود

نکات خیلی مهمی که باید از این سوال برای آزمون برداری

1) فرق Content-Type و Accept

این را باید تمیز بگویی:

• Content-Type = فرمت چیزی که من می‌فرستم

• Accept = فرمت چیزی که دوست دارم بگیرم

2) فرق 401 و 403

این برای آزمون خیلی مهم است:

• 401 Unauthorized → احراز هویت انجام نشده / توکن نیست / توکن نامعتبر است

• 403 Forbidden → کاربر شناخته شده ولی اجازه انجام این عملیات را ندارد

3) در تست‌کیس فقط اسم سناریو نده

برای نمره بهتر، تست‌کیس باید حداقل این‌ها را ضمنی یا صریح داشته باشد:

• Scenario

• Input / Headers

• Expected status code

• Expected business outcome
  مثلاً «customer ساخته نشود»

4) در سوال‌های Header فقط حفظی جواب نده

معمولاً ارزیاب دنبال این است که بفهمد آیا تو Header را به رفتار سیستم وصل می‌کنی یا نه.
یعنی فقط نگویی Authorization برای امنیت است؛ بگو:

• نبودنش چه status codeی باید بدهد

• invalid بودنش چه ریسکی دارد

• اگر API بدون آن 201 بدهد، Failure/Defect/Security Risk چیست

کلیدواژه‌های جدیدی که از همین سوال باید به لیستت اضافه کنیم

Content Negotiation (مکانیزمی که تعیین می‌کند پاسخ با چه فرمتی به Client برگردد): معمولاً با Accept و گاهی Content-Type در API Testing و تحلیل رفتار Response استفاده می‌شود.

Media Type (نوع داده‌ی HTTP مثل application/json یا text/plain): برای تحلیل Content-Type و Accept و بررسی سازگاری Request/Response با Contract استفاده می‌شود.

415 Unsupported Media Type (کد خطایی که نشان می‌دهد فرمت داده‌ی ارسالی توسط API پشتیبانی نمی‌شود): در تست Content-Type و Header Validation استفاده می‌شود.

Header Validation (اعتبارسنجی Headerهای ارسالی مثل Content-Type، Authorization، Accept): در تست منفی API و بررسی رعایت Contract و Security استفاده می‌شود.

Contract Enforcement (اجباری‌سازی و اعمال دقیق Contract توسط Server): وقتی بررسی می‌کنیم API واقعاً مطابق Swagger/OpenAPI رفتار می‌کند یا نه، از این مفهوم استفاده می‌شود.

Malformed Authorization Header (هدر Authorization با ساختار یا مقدار نادرست): در تست امنیت، تست توکن نامعتبر و بررسی 401 Unauthorized استفاده می‌شود.