طراحی تعاملی REST APIs با پروتکل HTTP

وب سرویس‌ها وب سرورهای هدفمندی هستند که نیازهای یک سایت یا هر برنامه دیگری را پشتیبانی می‌کنند. برنامه های مشتری از رابط‌های برنامه نویسی کاربردی (API) برای ارتباط با سرویس‌های وب استفاده می‌نمایند. به طور کلی، یک API مجموعه‌ای از داده‌ها و عملکردها را برای تسهیل تعامل بین برنامه‌های رایانه‌ای و اجازه تبادل اطلاعات به آن‌ها را در معرض نمایش می‌گذارد. همانطور که در تصویر زیر نشان داده شده است، یک Web API چهره یک سرویس وب است که مستقیماً به درخواست‌های مشتری گوش داده و به آنها پاسخ می‌دهد.

سبک معماری REST معمولاً برای طراحی API برای خدمات وب مدرن اعمال می‌شود. یک Web API مطابق با سبک معماری REST یک API REST است.

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

برای بسیاری از ما، طراحی REST API گاهی اوقات بیشتر شبیه یک هنر است تا علم. برخی از بهترین روش‌ها برای طراحی REST API به طور ضمنی در استاندارد HTTP وجود دارد، در حالی که سایر رویکردهای شبه استاندارد در چند سال گذشته ظهور کرده‌اند. با این حال، امروز، ما باید همچنان به دنبال پاسخ برای تعدادی از سوالات، مانند زیر ادامه دهیم:

چه زمانی باید بخش های مسیر URI با اسامی جمع نامگذاری شوند؟

کدام متد درخواست باید برای به روز رسانی وضعیت منبع استفاده شود؟

چگونه عملیات غیر CRUD را به URI های خود نگاشت کنم؟

کد وضعیت پاسخ HTTP مناسب برای یک سناریو چیست؟

چگونه می توانم نسخه های نمایش وضعیت یک منبع را مدیریت کنم؟

چگونه باید یک هایپرلینک را در JSON ساختار دهم؟

طراحی تعاملی با HTTP

HTTP/1.1

APIهای REST همه جنبه‌های پروتکل انتقال ابرمتن، نسخه 1.1* (HTTP/1.1) از جمله متد‌های درخواست، کدهای پاسخ و سرصفحه‌های پیام را در بر می‌گیرند.

متدهای درخواست

کلاینت ها متد تعامل مورد نظر را در قسمت Request-Line یک پیام درخواست HTTP مشخص می کنند. RFC 2616 دستور Request-Line را مطابق شکل زیر تعریف می کند:

Request-Line=Method SP Request-URI SP HTTP-Version CRLF

هر متد HTTP دارای معنایی خاص و کاملاً تعریف شده در چارچوب مدل منبع REST API است. هدف GET بازیابی نمایشی از وضعیت یک منبع است. HEAD برای بازیابی ابرداده های مرتبط با وضعیت منبع استفاده می شود. PUT باید برای افزودن یک منبع جدید به یک فروشگاه یا به روز رسانی یک منبع استفاده شود. DELETE یک منبع را از والد آن حذف می کند. POST باید برای ایجاد یک منبع جدید در یک مجموعه و اجرای کنترلرها استفاده شود.

قانون: GET و POST نباید برای تونل کردن متدهای درخواست دیگر استفاده شوند

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

قانون: برای بازیابی نمایشی از یک منبع باید از GET استفاده شود

یک سرویس گیرنده REST API از متد GET در یک پیام درخواست برای بازیابی وضعیت یک منبع، به شکلی نمایشی استفاده می کند. پیام درخواست GET مشتری ممکن است حاوی سرصفحه باشد اما فاقد بدنه باشد.
معماری وب به شدت بر ماهیت متد GET متکی است. مشتریان روی اینکه بتوانند درخواست های GET را بدون ایجاد عوارض جانبی تکرار کنند، حساب می کنند. کش ها به توانایی ارائه نمایش های کش شده بدون تماس با سرور مبدا بستگی دارند.
در مثال زیر، می‌توانیم ببینیم که چگونه یک توسعه‌دهنده مشتری ممکن است از curl از یک پوسته فرمان برای دریافت نمایشی از وضعیت فعلی یک منبع "سلام" استفاده کند:

  $ curl -v http://api.example.restapi.org/greeting
> GET /greeting HTTP/1.1
> User-Agent: curl/7.20.1
> Host: api.example.restapi.org
> Accept: */*
< HTTP/1.1 200 OK
< Date: Sat, 20 Aug 2011 16:02:40 GMT
< Server: Apache
< Expires: Sat, 20 Aug 2011 16:03:40 GMT
< Cache-Control: max-age=60, must-revalidate
< ETag: text/html:hello world
< Content-Length: 130
< Last-Modified: Sat, 20 Aug 2011 16:02:17 GMT
< Vary: Accept-Encoding
< Content-Type: text/html
Greeting
Hello World!

قانون: HEAD باید برای بازیابی هدرهای پاسخ استفاده شود

کلاینت ها از HEAD برای بازیابی هدرها بدون بدنه استفاده می کنند. به عبارت دیگر، HEAD همان پاسخ GET را برمی‌گرداند، با این تفاوت که API یک بدنه خالی را برمی‌گرداند. مشتریان می توانند از این متد برای بررسی وجود منبع یا خواندن ابرداده آن استفاده کنند.
مثال زیر دستور curl را برای بازیابی هدرها با متد HEAD نشان می دهد:

  $ curl --head http://api.example.restapi.org/greeting
HTTP/1.1 200 OK
Date: Sat, 20 Aug 2011 16:02:40 GMT
Server: Apache
Expires: Sat, 20 Aug 2011 16:03:40 GMT
Cache-Control: max-age=60, must-revalidate
ETag: text/html:hello world
Content-Length: 130
Last-Modified: Sat, 20 Aug 2011 16:02:17 GMT
Vary: Accept-Encoding
Content-Type: text/html

قانون: PUT باید برای درج و به‌روزرسانی یک منبع ذخیره شده استفاده شود

PUTباید برای افزودن یک منبع جدید به یک فروشگاه با یک URI مشخص شده توسط مشتری استفاده شود.
PUT همچنین باید برای به روز رسانی یا جایگزینی یک منبع ذخیره شده از قبل استفاده شود.
مثال زیر نشان می‌دهد که چگونه یک REST API سرویس‌گرا می‌تواند منبع ذخیره‌سازی را فراهم کند که به برنامه‌های مشتری خود اجازه می‌دهد تا داده‌های خود را بعنوان اشیا حفظ کنند:

  PUT /accounts/4ef2d5d0-cb7e-11e0-957209a66/buckets/objects/4321

پیام درخواست PUT باید شامل نمایش منبعی باشد که مشتری می خواهد ذخیره کند. با این حال، متن درخواست ممکن است دقیقاً همان چیزی باشد که مشتری از یک درخواست GET بعدی دریافت می کند یا نه. به عنوان مثال، منبع ذخیره REST API ممکن است به مشتریان اجازه دهد فقط بخش‌های قابل تغییر وضعیت منبع را در نمایش پیام درخواست لحاظ کنند.

قانون: برای به روز رسانی منابع قابل تغییر باید از PUT استفاده شود

مشتریان باید از متد درخواست PUT برای ایجاد تغییرات در منابع استفاده کنند. پیام درخواست PUT ممکن است شامل بدنه ای باشد که تغییرات مورد نظر را منعکس می کند.

قانون: POST باید برای ایجاد یک منبع جدید در یک مجموعه استفاده شود

هنگام تلاش برای ایجاد یک منبع جدید در یک مجموعه، مشتریان از POST استفاده می کنند. بدنه درخواست POST حاوی نمایش وضعیت پیشنهادی منبع جدید است که باید به مجموعه متعلق به سرور اضافه شود.
مثال زیر نشان می دهد که چگونه یک کلاینت از POST برای درخواست افزودن جدید به مجموعه استفاده می کند:

  POST /leagues/seattle/teams/trebuchet/players
# Note the request message may contain a representation that suggests the initial state
of the player to be created.

این اولین مورد از دو استفاده از متد POST در زمینه طراحی REST API است. از نظر استعاری، این استفاده از POST مشابه «پست کردن» یک پیام جدید در تابلوی اعلانات است.

قانون: برای اجرای کنترلرها باید از POST استفاده شود

کلاینت ها از متد POST برای فراخوانی منابع کنترل کننده تابع گرا استفاده می کنند. یک پیام درخواست POST ممکن است شامل سرصفحه ها و بدنه به عنوان ورودی عملکرد یک منبع کنترل کننده باشد.
HTTP POST را از نظر معنایی با پایان باز تعیین می کند. این متد اجازه می دهد تا بدون توجه به تکرارپذیری یا عوارض جانبی، هر اقدامی را انجام دهد. این امر POST را به انتخاب واضحی برای جفت شدن با منابع کنترل کننده به همان اندازه نامحدود تبدیل می کند.
طراحی‌های REST API ما از POST، همراه با یک منبع کنترل‌کننده هدفمند، برای راه‌اندازی تمام عملیات‌هایی که نمی‌توانند به طور مستقیم به یکی از متد‌های اصلی HTTP دیگر نگاشت شوند، استفاده می‌کنند.
به عبارت دیگر، متد POST نباید برای دریافت، ذخیره یا حذف منابع استفاده شود - HTTP از قبل متدهای خاصی را برای هر یک از آن توابع ارائه می دهد.HTTP متد درخواست POST را ناامن و غیر توانمند می نامد، به این معنی که نتیجه آن غیرقابل پیش بینی است و تضمینی برای تکرار بدون عوارض جانبی بالقوه نامطلوب نیست. به عنوان مثال، یک فرم وب ارسال شده مجدد که از POST استفاده می کند ممکن است خطر صدور صورت حساب مضاعف کارت اعتباری کاربر را به همراه داشته باشد. منابع کنترل کننده درجه ای از شفافیت و استحکام را به خاطر انعطاف پذیری ردوبدل می کنند. مثال زیر نشان می دهد که چگونه یک کنترلر را می توان با استفاده از متد درخواست POST اجرا کرد:

  POST /alerts/245743/resend

این دومین استفاده از POST در طراحی API های REST است. این مورد استفاده شبیه مفهوم نسبتاً رایج مکانیزم «PostMessage» سیستم زمان اجرا است که به توابع اجازه فراخوانی در یک نوع محدوده را می دهد.

قانون: DELETE باید برای حذف یک منبع از والد آن استفاده شود

یک سرویس گیرنده از DELETE برای درخواست حذف کامل یک منبع از والد خود، که اغلب یک مجموعه یا فروشگاه است، استفاده می کند. هنگامی که یک درخواست DELETE برای یک منبع معین پردازش شد، دیگر نمی‌توان آن منبع را توسط مشتریان پیدا کرد. بنابراین، هر تلاشی در آینده برای بازیابی نمایش وضعیت منبع، با استفاده از GET یا HEAD، باید منجر به وضعیت 404 («یافت نشد») شود که توسط API بازگردانده می‌شود.
مثال زیر نشان می دهد که چگونه یک مشتری ممکن است یک سند را از یک فروشگاه حذف کند:

 DELETE /accounts/4ef2d5d0-cb7e-11e0-9572-080020/buckets/objects/4321

متد DELETE معنایی بسیار خاصی در HTTP دارد که نباید توسط طراحی REST API بارگذاری یا کشیده شود. به طور خاص، یک API نباید معنای مورد نظر DELETE را با نگاشت آن به یک اقدام کمتر که منبع و URI آن را در دسترس مشتریان قرار می دهد، تحریف کند. به عنوان مثال، اگر یک API بخواهد یک حذف "نرم" یا یک تعامل تغییر وضعیت دیگر ارائه دهد، باید از یک منبع کنترل کننده ویژه استفاده کند و مشتریان خود را به استفاده از POST به جای DELETE برای تعامل هدایت کند.

قانون: برای بازیابی ابرداده‌هایی که تعاملات موجود یک منبع را توصیف می‌کنند، باید از OPTIONS استفاده شود.

کلاینت ها ممکن است از متد درخواست OPTIONS برای بازیابی ابرداده منبعی که شامل مقدار هدر Allow است استفاده کنند. مثلا:

Allow: GET, PUT, DELETE

در پاسخ به درخواست OPTIONS، یک REST API ممکن است شامل بدنه‌ای باشد که شامل جزئیات بیشتر در مورد هر گزینه تعامل باشد.

کدهای وضعیت پاسخ HTTP

APIهای REST از بخش Status-Line یک پیام پاسخ HTTP استفاده می کنند تا مشتریان را از نتیجه کلی درخواست خود مطلع کنند. RFC 2616 نحو Status-Line را مطابق شکل زیر تعریف می کند:

Status-Line=HTTP-Version SP Status-code SP Reason-Phrase CRLF

دسته بندی	توصیف
1xx - اطلاعاتی	انتقال اطلاعات در سطح پروتکل.
2xx - موفق	نشان می دهد که درخواست مشتری با موفقیت پذیرفته شده است.
3xx - تغییرمسیر	نشان می دهد که مشتری برای تکمیل درخواست خود باید اقدامات اضافی انجام دهد.
4xx - خطامشتری	این دسته از کدهای وضعیت خطا انگشت را به سمت مشتریان نشانه می رود.
5xx -خطاسرور	سرور مسئولیت این کدهای وضعیت خطا را بر عهده می گیرد.

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

قانون: 200 ("OK") باید برای نشان دادن موفقیت غیر اختصاصی استفاده شود

در بیشتر موارد، 200 کدی است که مشتری امیدوار است ببیند. این نشان می دهد که REST API هر اقدامی را که مشتری درخواست کرده بود با موفقیت انجام داد و هیچ کد خاصی در سری 2xx مناسب نیست. برخلاف کد وضعیت 204، یک پاسخ 200 باید شامل بدنه پاسخ باشد.

قانون: 200 ("OK") نباید برای ارتباط خطاها در بدنه پاسخ استفاده شود.

همیشه از کدهای وضعیت پاسخ HTTP همانطور که در قوانین این بخش مشخص شده است استفاده درستی کنید. به طور خاص، یک REST API نباید در تلاش برای تطبیق با مشتریان HTTP پیچیده تر به خطر بیفتد.

قانون: 201 ("Created") باید برای نشان دادن ایجاد موفقیت آمیز منبع استفاده شود

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

قانون: 202 ("Accepted") باید برای نشان دادن شروع موفقیت آمیز یک عمل ناهمزمان استفاده شود

پاسخ 202 نشان می دهد که درخواست مشتری به صورت ناهمزمان رسیدگی می شود. این کد وضعیت پاسخ به مشتری می‌گوید که درخواست معتبر به نظر می‌رسد، اما پس از پردازش نهایی ممکن است همچنان مشکل داشته باشد. پاسخ 202 معمولاً برای اقداماتی استفاده می شود که پردازش آنها زمان زیادی می برد.

قانون: 204 ("No Content") باید زمانی استفاده شود که بدنه پاسخ به عمد خالی است

کد وضعیت 204 معمولاً در پاسخ به درخواست PUT، POST یا DELETE ارسال می‌شود، زمانی که REST API از ارسال هرگونه پیام وضعیت یا نمایشی در بدنه پیام پاسخ امتناع می‌کند. یک API همچنین ممکن است 204 را همراه با یک درخواست GET ارسال کند تا نشان دهد که منبع درخواستی وجود دارد، اما هیچ نمایش حالتی برای گنجاندن در بدنه ندارد.

قانون: 301 ("Moved Permanently") باید برای جابجایی منابع استفاده شود

کد وضعیت 301 نشان می دهد که مدل منبع REST API به طور قابل توجهی دوباره طراحی شده است و یک URI دائمی جدید به منبع درخواستی مشتری اختصاص داده شده است. REST API باید URI جدید را در هدر مکان پاسخ مشخص کند

قانون: 302 ("Found") نباید استفاده شود

معنای مورد نظر کد پاسخ 302 توسط برنامه نویسان به اشتباه درک شده و از نسخه 1.0 پروتکل HTTP به اشتباه در برنامه ها پیاده سازی شده است. این سردرگمی بر این متمرکز است که آیا مناسب است یک کلاینت بدون توجه به متد درخواست اصلی، همیشه به طور خودکار یک درخواست GET پیگیری را برای URI در هدر موقعیت مکانی پاسخ دهد یا خیر. برای ثبت، هدف 302 این است که این رفتار تغییر مسیر خودکار فقط در صورتی اعمال می شود که درخواست اصلی مشتری از متد GET یا HEAD استفاده کند. برای روشن کردن همه چیز، HTTP 1.1 کدهای وضعیت 303 («مشاهده سایرین») و 307 («تغییر مسیر موقت») را معرفی کرد، که هر کدام باید به جای 302 استفاده شوند.

قانون: 303 ("See Other") باید برای ارجاع مشتری به یک URI دیگر استفاده شود

پاسخ 303 نشان می دهد که یک منبع کنترل کننده کار خود را به پایان رسانده است، اما به جای ارسال یک بدنه پاسخ ناخواسته، URI یک منبع پاسخ را برای مشتری ارسال می کند. این می تواند URI یک پیام وضعیت موقت یا URI یک منبع از قبل موجود، دائمی تر باشد.
به طور کلی، کد وضعیت 303 به یک API REST اجازه می دهد تا یک مرجع را به یک منبع ارسال کند بدون اینکه مشتری را مجبور به دانلود وضعیت آن کند. درعوض، مشتری ممکن است یک درخواست GET به مقدار هدر Location ارسال کند.

قانون: 304 ("Not Modified") باید برای حفظ پهنای باند استفاده شود

این کد وضعیت مشابه 204 ("بدون محتوا") است که بدنه پاسخ باید خالی باشد. تمایز اصلی این است که 204 زمانی استفاده می شود که چیزی برای ارسال در بدنه وجود نداشته باشد، در حالی که 304 زمانی استفاده می شود که اطلاعات وضعیت مرتبط با یک منبع وجود دارد اما مشتری از قبل آخرین نسخه نمایش را دارد.

قانون: 307 ("Temporary Redirect") باید برای گفتن به مشتریان برای ارسال مجدد درخواست به URI دیگر استفاده شود.

1.1HTTP/ کد وضعیت 307 را برای تکرار معنایی اصلی کد وضعیت 302 («یافت شده») معرفی کرد. پاسخ 307 نشان می دهد که REST API قرار نیست درخواست مشتری را پردازش کند. در عوض، مشتری باید درخواست را مجدداً به URI مشخص شده توسط هدر موقعیت پیام پاسخ ارسال کند. یک REST API می تواند از این کد وضعیت برای اختصاص یک URI موقت به منبع درخواستی مشتری استفاده کند. به عنوان مثال، یک پاسخ 307 می تواند برای انتقال درخواست مشتری به میزبان دیگری استفاده شود.

قانون: 400 ("Bad Request") ممکن است برای نشان دادن خرابی غیر اختصاصی استفاده شود

400 وضعیت خطای عمومی سمت کلاینت است که زمانی استفاده می شود که هیچ کد خطای 4xx دیگری مناسب نباشد.

قانون: 401 ("Unathorized") باید در صورت وجود مشکل در اعتبار مشتری استفاده شود

پاسخ خطای 401 نشان می دهد که مشتری تلاش کرده است تا بدون ارائه مجوز مناسب روی یک منبع محافظت شده کار کند. ممکن است اعتبارنامه اشتباهی ارائه کرده باشد یا اصلاً وجود نداشته باشد.

قانون: 403 ("Forbidden") باید برای ممنوع کردن دسترسی بدون توجه به آن استفاده شود وضعیت مجوز

پاسخ خطای 403 نشان می دهد که درخواست مشتری به درستی شکل گرفته است، اما REST API از رعایت آن خودداری می کند. پاسخ 403 موردی نیست که اعتبار مشتری کافی نباشد. که 401 خواهد بود ("غیر مجاز"). API های REST از 403 برای اعمال مجوزهای سطح برنامه استفاده می کنند. به عنوان مثال، ممکن است یک کلاینت مجاز باشد که با برخی منابع REST API، اما نه همه، تعامل داشته باشد. اگر مشتری یک تعامل با منبعی را انجام دهد که خارج از محدوده مجاز آن است، REST API باید با 403 پاسخ دهد.

قانون: 404 ("Not Found") باید زمانی استفاده شود که URI مشتری نمی تواند به یک منبع نگاشت شود.

کد وضعیت خطای 404 نشان می دهد که REST API نمی تواند URI مشتری را به یک منبع نگاشت کند.

قانون: 405 ("Method Not Allowed") زمانی که متد HTTP پشتیبانی نمی شود باید استفاده شود

API با یک خطای 405 پاسخ می دهد تا نشان دهد که مشتری سعی کرده از متد HTTP استفاده کند که منبع اجازه نمی دهد. به عنوان مثال، یک منبع فقط خواندنی می تواند فقط GET و HEAD را پشتیبانی کند، در حالی که یک منبع کنترل کننده ممکن است به GET و POST اجازه دهد، اما نه PUT یا DELETE.
یک پاسخ 405 باید شامل هدر Allow باشد که متدهای HTTP را که منبع پشتیبانی می کند فهرست می کند. مثلا:

Allow: GET, POST

قانون: 406 ("Not Acceptable") باید زمانی استفاده شود که نوع رسانه درخواستی قابل ارائه نباشد

پاسخ خطای 406 نشان می‌دهد که API قادر به تولید هیچ یک از انواع رسانه‌های ترجیحی مشتری نیست، همانطور که توسط هدر درخواست پذیرش نشان داده شده است. به عنوان مثال، یک درخواست مشتری برای داده های فرمت شده به عنوان application/xml، در صورتی که API فقط مایل به قالب بندی داده ها به عنوان application/json باشد، پاسخ 406 را دریافت می کند.

قانون: 409 ("Conflict") باید برای نشان دادن نقض وضعیت منبع استفاده شود

پاسخ خطای 409 به مشتری می گوید که آنها سعی کرده اند منابع REST API را در حالت غیرممکن یا ناسازگار قرار دهند. به عنوان مثال، یک REST API ممکن است این کد پاسخ را هنگامی که یک مشتری سعی می کند یک منبع فروشگاه غیرخالی را حذف کند، بازگرداند.

قانون: 412 ("Precondition Failed") باید برای پشتیبانی از عملیات مشروط استفاده شود

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

قانون: 415 ("Unsupported Media Type") زمانی باید استفاده شود که نوع رسانه یک بار درخواست قابل پردازش نباشد.

پاسخ خطای 415 نشان می‌دهد که API نمی‌تواند نوع رسانه ارائه‌شده مشتری را پردازش کند، همانطور که در سربرگ درخواست نوع محتوا نشان داده شده است. برای مثال، اگر API فقط مایل به پردازش داده‌های قالب‌بندی‌شده به‌عنوان application/json باشد، یک درخواست کلاینت شامل داده‌های قالب‌بندی‌شده به‌عنوان application/xml، پاسخ 415 را دریافت می‌کند.

قانون: 500 ("Internal Server Error") باید برای نشان دادن API استفاده شود اشکال در عملکرد

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

شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه ارزیابی و پایش کارایی نرم افزار ارائه می دهد:

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

اجرای آزمون‌های بار و فشار برروی سامانه های نرم افزاری

تهیه و آموزش ابزارهای تست پرفورمنس (تست بار و فشار) همچون WPLT و LoadTest

پایش و مانیتورینگ شاخص های کارایی سامانه های نرم افزاری از طریق ابزارهای مدیریت کارایی همچون AppDynamicsو DynaTrace

نویسنده : شرکت مهندس پیشگان آزمون افزار یاس

مراجع