نمونه‌هایی از وب‌سایت‌ها و شرکت‌های بزرگ که استانداردهای مشخص‌شده را رعایت نکرده‌اند 1. Dropbox - مشکل: استفاده از یک متد HTTP (POST) برای همه درخواست‌ها - توضیح: در نسخه‌های اولیه API خود، تقریباً همه درخواست‌ها (حتی موارد مربوط به خواندن داده‌ها) را با متد POST انجام می‌داد. این در حالی است که طبق استاندارد HTTP، متدهای GET باید برای دریافت داده‌ها استفاده شوند و نیازی به ارسال داده در بدنه (Body) نیست. 2. Twitter - مشکل: استفاده از Query String برای ارسال اطلاعات حساس - توضیح:   در نسخه‌های اولیه API توییتر، برخی از درخواست‌های احراز هویت (مانند ارسال کلید API یا Access Token) از طریق Query String انجام می‌شد. این روش باعث می‌شد که اطلاعات حساس در URL ذخیره شوند و در لاگ‌های سرور یا مرورگر ثبت شوند.   چرا استاندارد نیست؟   طبق اصول امنیتی، اطلاعات حساس باید در بدنه درخواست (Body) یا هدر (Header) ارسال شوند، نه در Query String. 3. GitHub - مشکل: استفاده از Status Code 404 برای پنهان کردن اطلاعات - توضیح: گیت هاب در برخی از APIهای خود، وقتی کاربری به یک منبع غیرمجاز دسترسی پیدا می‌کند (مثلاً یک ریپازیتوری خصوصی)، به جای استفاده از کد وضعیت 403 Forbidden، کد 404 Not Found را برمی‌گرداند. این کار برای جلوگیری از افشای وجود منابعی که کاربر به آن‌ها دسترسی ندارد انجام می‌شود. 4. Facebook - مشکل: عدم استفاده صحیح از محدودیت نرخ (Rate Limit) در برخی نسخه‌های اولیه API - توضیح:   در نسخه‌های اولیه API فیس‌بوک، محدودیت نرخ (Rate Limit) به صورت یکنواخت برای همه کاربران اعمال نمی‌شد و رفتار مشخصی برای درخواست‌های بیش از حد وجود نداشت. گاهی درخواست‌های اضافی به صورت موفقیت‌آمیز پاسخ داده می‌شدند، اما در برخی موارد دیگر خطای غیرشفاف بازگردانده می‌شد. 5. Instagram - مشکل: استفاده از کد وضعیت 200 برای خطاها - توضیح:   در API اینستاگرام، در برخی از نسخه‌های قدیمی، خطاها (مانند درخواست‌های نامعتبر) با کد وضعیت 200 OK بازگشت داده می‌شدند و جزئیات خطا در بدنه پاسخ قرار می‌گرفت. 6. PayPal - مشکل: استفاده از کدهای وضعیت غیررایج - توضیح:   در برخی پاسخ‌های APIهای قدیمی PayPal، کدهای وضعیت غیررایج یا غیرمستند (مانند 490) ارسال می‌شدند. این کدها در مستندات HTTP تعریف نشده‌اند و کلاینت‌ها نمی‌توانند به درستی آن‌ها را پردازش کنند. 7. Amazon S3 - مشکل: استفاده از کد وضعیت 200 برای پاسخ‌های جزئی - توضیح:   در برخی از عملیات S3 (مانند لیست کردن اشیاء در یک باکت بزرگ)، اگر پاسخ به دلیل محدودیت اندازه به صورت چندبخشی باشد (Partial Response)، همچنان کد وضعیت 200 OK بازگردانده می‌شود.   چرا استاندارد نیست؟   برای پاسخ‌هایی که تنها بخشی از داده‌ها را شامل می‌شوند، استاندارد HTTP کد 206 Partial Content را پیشنهاد می‌کند. 8. LinkedIn - مشکل: ساختار غیریکسان در پاسخ‌های JSON - توضیح: در برخی از نسخه‌های قدیمی APIهای لینکدین، ساختار پاسخ‌های JSON در درخواست‌های مختلف یکنواخت نبود. مثلاً کلیدها در یک پاسخ به صورت snake_case و در پاسخ دیگر به صورت camelCase بودند. چرا استاندارد نیست؟ یکی از اصول طراحی API این است که ساختار پاسخ‌ها باید یکنواخت باشد تا توسعه‌دهندگان بتوانند به راحتی آن‌ها را پردازش کنند. 9. Google Maps API مشکل: ارسال داده‌های غیرضروری در پاسخ‌ها - توضیح: در برخی پاسخ‌های Google Maps API، مقادیر غیرضروری و اضافی که گاهی هیچ ارتباطی با درخواست کاربر ندارند، بازگردانده می‌شدند. این می‌تواند باعث افزایش حجم داده و تأخیر در پردازش شود. @Syntax_fa