REST API چیست؟

عمومی
مدیر سایت

REST API چیست؟

REST API چیست؟ REST مخفف Representational State Transfer است – توصیف تقریباً بی معنی از پر استفاده ترین فناوری وب سرویس! REST API راهی برای دو سیستم کامپیوتری برای ارتباط با استفاده از فناوری‌های HTTP موجود در مرورگرها و سرورهای وب است.

به اشتراک گذاری داده ها بین دو یا چند سیستم همیشه یک نیاز اساسی توسعه نرم افزار بوده است. به عنوان مثال، خرید بیمه موتور را در نظر بگیرید. بیمه‌گر شما باید اطلاعاتی درباره شما و وسیله نقلیه‌تان به دست آورد تا از مقامات ثبت خودرو، آژانس‌های اعتباری، بانک‌ها و سایر سیستم‌ها اطلاعات درخواست کند. همه اینها به صورت شفاف در زمان واقعی اتفاق می افتد تا مشخص شود آیا بیمه گر می تواند یک بیمه نامه رقابتی ارائه دهد.طراحی سایت

API ها (رابط های برنامه نویسی کاربردی) به این نوع ارتباط بین سیستم ها با ارائه یک رابط برای صحبت آنها با یکدیگر کمک می کنند. REST به سادگی یک سبک رایج از API است که ما از آن برای برقراری ارتباط با طرف های داخلی و خارجی به روشی سازگار و قابل پیش بینی استفاده می کنیم. می توان آن را با نحوه ارسال نامه با تمبر پستی، آدرس و پاکت به روشی خاص مقایسه کرد تا از تحویل و خواندن آن اطمینان حاصل شود.

REST معمولاً توسط افراد در سیستم های وب برای تعامل با یکدیگر استفاده می شود. برای مثال، بازیابی و به‌روزرسانی اطلاعات حساب در یک برنامه رسانه اجتماعی.

یک مثال REST API

پیوند زیر را در مرورگر خود باز کنید تا از باز کردن پایگاه داده‌های Triviaدرخواست یک سؤال رایانه‌ای تصادفی کنید. >:

https://opentdb.com/api.php؟ مبلغ=1&category=18

این یک API عمومی است که به عنوان وب سرویس RESTful پیاده سازی شده است (از قراردادهای REST پیروی می کند). مرورگر شما یک سوال مسابقه با قالب JSON را با پاسخ هایی مانند:

نشان می دهد

{
  "response_code": 0،
  "نتایج": [
    {
      "رده": "علم: کامپیوتر"،
      "نوع": "چند"،
      "مشکل": "آسان"،
      "سوال": "گیگاهرتز مخفف چیست؟"،
      "correct_answer": "گیگاهرتز"،
      "پاسخ_نادرست": [
        "گیگاهوتز"،
        "گیگاهتز"،
        "گیگاهتز"
      ]
    }
  ]
}

می توانید همان URL را درخواست کنید و با استفاده از هر مشتری HTTP، مانند curl، پاسخ دریافت کنید:

فرش "https://opentdb .com/api.php?amount=1&category=18"

کتابخانه‌های سرویس گیرنده HTTP به همه زبان‌ها و زمان‌های اجرا معروف از جمله واکشی در JavaScript، Node در دسترس هستند. js و Deno و file_get_contents() در PHP. پاسخ JSON قابل خواندن توسط ماشین است، بنابراین می توان آن را قبل از خروجی HTML یا فرمت های دیگر تجزیه و استفاده کرد.

REST APIها و بقیه

استانداردهای مختلف ارتباط داده در طول سال ها تکامل یافته اند. ممکن است با گزینه هایی از جمله CORBA، SOAP یا XML-RPC. اکثر قوانین سختگیرانه ارسال پیام.

REST در سال 2000 توسط روی فیلدینگ تعریف شد و بسیار ساده تر از بقیه است. این یک استاندارد نیست، بلکه مجموعه ای از توصیه ها و محدودیت ها برای خدمات وب RESTful است. این موارد عبارتند از:

  • Client-Server: SystemA یک درخواست HTTP به نشانی اینترنتی میزبانی شده توسط SystemB می‌دهد، که پاسخی را برمی‌گرداند. این با نحوه عملکرد مرورگر یکسان است. یک مرورگر یک URL خاص را درخواست می کند. درخواست به یک وب سرور هدایت می شود که معمولاً یک صفحه HTML را برمی گرداند. آن صفحه ممکن است حاوی ارجاعاتی به تصاویر، شیوه نامه ها و جاوا اسکریپت باشد که درخواست ها و پاسخ های بیشتری را به همراه دارد.
  • Stateless: REST بدون حالت است: درخواست مشتری باید حاوی تمام اطلاعات لازم برای پاسخ باشد. به عبارت دیگر، باید امکان ایجاد دو یا چند درخواست HTTP به هر ترتیبی وجود داشته باشد. پاسخ‌ها دریافت خواهند شد (… مگر اینکه API برای بازگرداندن پاسخ‌های تصادفی مانند مثال مسابقه بالا طراحی شده باشد).
  • قابل ذخیره سازی: یک پاسخ باید به عنوان قابل ذخیره سازی در حافظه پنهان تعریف شود یا خیر. ذخیره سازی در حافظه پنهان عملکرد را بهبود می بخشد زیرا نیازی به ایجاد مجدد پاسخ برای همان URL نیست. داده‌های خصوصی خاص یک کاربر خاص در یک زمان خاص معمولاً در حافظه پنهان ذخیره نمی‌شوند.
  • لایه‌ای: کلاینت درخواست‌کننده نباید بداند که آیا با سرور واقعی، یک پروکسی یا هر واسطه دیگری در ارتباط است.

معرفی سایت: https://ifmee.ir/آیا-رسانه-های-اجتماعی-به-کسب-و-کار-طراحی/

ایجاد یک وب سرویس RESTful

یک درخواست سرویس وب RESTful شامل:

است

  1. نشانی اینترنتی نقطه پایانی. برنامه‌ای که یک RESTful API را پیاده‌سازی می‌کند، یک یا چند نقطه پایانی URL را با یک دامنه، پورت، مسیر، و/یا رشته پرس و جو تعریف می‌کند – برای مثال، https://mydomain/user/123?format=json .
  2. روش HTTP. روش‌های مختلف HTTP را می‌توان در هر نقطه پایانی استفاده کرد که نقشه عملیات ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) برنامه را دارد:
    روش HTTP CRUD عمل
    دریافت خواندن داده های درخواستی را برمی گرداند
    POST ایجاد یک رکورد جدید ایجاد می کند
    PUT یا PATCH به روز رسانی یک رکورد موجود را به روز می کند
    حذف حذف یک رکورد موجود را حذف می کند

    مثال:

      • یک درخواست GET به /user/ لیستی از کاربران ثبت شده در یک سیستم را برمی گرداند
      • یک درخواست POST به /user/ یک کاربر با شناسه 123 با استفاده از داده‌های بدن ایجاد می‌کند (به 4. زیر مراجعه کنید). پاسخ شناسه را برمی گرداند.
      • یک درخواست PUT برای /user/123 کاربر 123 را با داده‌های بدن به‌روزرسانی می‌کند (به 4. زیر مراجعه کنید)
      • یک درخواست GET به /user/123 جزئیات کاربر 123

    را برمی‌گرداند

      • درخواست DELETE به /user/123 کاربر 123

    را حذف می‌کند

  3. هدرهای HTTP. اطلاعاتی مانند ژتون‌های احراز هویت یا کوکی‌ها را می‌توان در سرصفحه درخواست HTTP قرار داد.
  4. داده های بدن. داده‌ها معمولاً در بدنه HTTP به روشی مشابه با ارسال‌های

    HTML یا با ارسال یک رشته داده با کد JSON منتقل می‌شوند.

پاسخ REST API

بار پاسخ می تواند هر چیزی که عملی است باشد: داده، HTML، یک تصویر، یک فایل صوتی و غیره. پاسخ‌های داده معمولاً با کد JSON کدگذاری می‌شوند، اما XML، CSV، رشته‌های ساده یا هر قالب دیگری می‌توانند مورد استفاده قرار گیرد. می‌توانید اجازه دهید قالب بازگشتی در درخواست مشخص شود – برای مثال، /user/123?format=json یا /user/123?format=xml.

یک کد وضعیت HTTP مناسب نیز باید در سرصفحه پاسخ تنظیم شود. 200 OK برای درخواست‌های موفق استفاده می‌شود، اگرچه 201 Created نیز می‌تواند هنگام ایجاد یک رکورد برگردانده شود. خطاها باید کد مناسبی مانند 400 درخواست بد، 404 یافت نشد، 401 غیر مجاز و غیره را برگردانند.

سایر سرصفحه‌های HTTP را می‌توان تنظیم کرد، از جمله Cache-Control یا دستورالعمل‌های انقضا برای تعیین مدت زمانی که می‌توان یک پاسخ را قبل از رسیدن به حافظه پنهان نگه داشت. کهنه در نظر گرفته شده است.

با این حال، قوانین سختگیرانه ای وجود ندارد. نشانی‌های وب نقطه پایانی، روش‌های HTTP، داده‌های بدنه و انواع پاسخ‌ها را می‌توان به دلخواه پیاده‌سازی کرد. برای مثال، POST، PUT و PATCH اغلب به جای یکدیگر استفاده می‌شوند، بنابراین هر کدام در صورت لزوم یک رکورد ایجاد یا به‌روزرسانی می‌کنند.

مثال REST API “Hello World”

کد Node.js زیر یک سرویس وب RESTful را با استفاده از چارچوب Express ایجاد می‌کند. یک نقطه پایانی /hello/ به درخواست‌های HTTP GET پاسخ می‌دهد.

مطمئن شوید که Node.js را نصب کرده اید، سپس یک پوشه جدید به نام restapi. یک فایل package.json جدید در آن پوشه با محتوای زیر ایجاد کنید:

{
  "name": "restapi"،
  "نسخه": "1.0.0"،
  "توضیحات": "آزمون REST"،
  "اسکریپت ها": {
    "شروع": "node ./index.js"
  }،
  "وابستگی ها": {
    "express": "4.18.1"
  }
}

npm install را از خط فرمان برای واکشی وابستگی ها اجرا کنید، سپس یک فایل index.js با کد زیر ایجاد کنید:


'استفاده از سخت گیری';


const
  پورت = 8888،
  بیان = نیاز('express')،
  برنامه = express();


برنامه.دریافت('/hello/:name?'، (req، پاسخ) = 
  res.json(
    { پیام: `سلام ${req.پارام.نام || 'world'}!` }
  )
);


برنامه.گوش دادن(port، ()  =>
  کنسول.ورود(` سرور در پورت شروع شد ${port}`);
);

برنامه را از خط فرمان با استفاده از npm start راه اندازی کنید و http://localhost:8888/hello/ را در مرورگر باز کنید. JSON زیر در پاسخ به درخواست GET نمایش داده می شود:

{
  "پیام": "سلام دنیا!"
}

API همچنین اجازه یک نام سفارشی را می‌دهد، بنابراین http://localhost:8888/hello/everyone/ برمی‌گرداند:

{
  "پیام": "سلام به همه!"
}

درخواست‌های REST سمت مشتری و CORS

صفحه HTML زیر را در نظر بگیرید که در یک مرورگر به آدرس http://localhost:8888/:

راه اندازی شده است.

DOCTYPE html>
html lang="en">
سر>
متا مجموعه نویسه="UTF-8">
title>آزمون RESTtitle>
سر>
body>
اسکریپت>
واکشی('http://localhost:8888/hello/')
  .سپس((پاسخ) =>  {
    بازگشت پاسخ.json ();
  })
  .سپس((json) =>  {
    کنسول.ورود(json);
  });
script>
body>
html>

تماس fetch همان درخواست API را انجام می دهد و کنسول مرورگر Object { پیام: "سلام دنیا!" } همانطور که انتظار دارید.

با این حال، فرض کنید سرویس وب RESTful شما اکنون در دامنه http://mydomain.com/hello/ به صورت زنده در وب قرار گرفته است. URL صفحه جاوا اسکریپت fetch() بر این اساس تغییر کرده است، اما باز کردن http://localhost:8888/ در مرورگر اکنون خطای کنسول درخواست متقاطع را برمی‌گرداند. مسدود شده.

برای امنیت، مرورگرها فقط به سمت سرویس گیرنده اجازه XMLHttpRequest و واکشی API به همان دامنه ای که صفحه تماس میزبانی می شود، تماس می گیرد.

خوشبختانه، اشتراک‌گذاری منابع متقاطع (CORS) به ما امکان می‌دهد دور بزنیم آن محدودیت امنیتی تنظیم سرصفحه پاسخ HTTP Access-Control-Allow-Origin به مرورگرها می گوید که اجازه درخواست را می دهند. می‌توان آن را روی یک دامنه خاص یا * برای همه دامنه‌ها (که توسط Quiz API در بالا پیاده‌سازی شد) تنظیم کرد.

کد API سرویس وب را می توان تغییر داد تا امکان دسترسی از هر اسکریپت سمت سرویس گیرنده ای که در هر دامنه اجرا می شود، فراهم شود:


برنامه.دریافت('/hello/:name?'، (req، پاسخ) = 
  پاسخ
    .append('Access-Control-Allow-Origin'، '*')
    .json(
      { پیام: `سلام ${req.پارام.نام || 'world'}!` }
    )
);

از طرف دیگر، یک تابع میان‌افزار Express.js می‌تواند هدر را به هر درخواست نقطه پایانی اضافه کند:


برنامه.استفاده از((req, res، بعدی) => {
  Res.append('Access-Control-Allow-Origin'، '*');
  بعدی();
});

توجه داشته باشید که مرورگرها دو درخواست به REST API ارسال می‌کنند:

  1. یک درخواست HTTP OPTIONS به همان URL تعیین می کند که آیا سرصفحه پاسخ HTTP Access-Control-Allow-Origin معتبر است
  2. تماس REST واقعی

زمانی که سرور شما یک روش درخواست OPTIONS دریافت می‌کند، می‌تواند سرصفحه پاسخ HTTP Access-Control-Allow-Origin را برای اطمینان از یک پاسخ خالی ساختگی تنظیم کند. کار تکراری نیست.

چالش های REST API

موفقیت REST مدیون سادگی آن است. توسعه دهندگان آزادند تا API های RESTful را هر طور که دوست دارند پیاده کنند، اما می تواند منجر به چالش های بیشتر شود. برای نگاهی عمیق به استراتژی‌های پیاده‌سازی، نگاهی به 13 بهترین روش برای ایجاد APIهای RESTful ما بیندازید.

اجماع نقطه پایانی

نقاط پایانی زیر را در نظر بگیرید:

  • /user/123
  • /user/id/123
  • /user/?id=123

همه گزینه‌های معتبری برای واکشی داده‌ها برای کاربر 123 هستند. وقتی عملیات پیچیده‌تری دارید، تعداد ترکیب‌ها بیشتر می‌شود. به عنوان مثال، ده کاربر را برگردانید که نام خانوادگی آنها با “A” شروع می شود و برای companyX از رکورد 51 شروع می شود، زمانی که بر اساس تاریخ تولد به ترتیب زمانی معکوس مرتب می شوند.

در نهایت، نحوه قالب بندی URL ها اهمیتی ندارد، اما ثبات در API شما مهم است. این می‌تواند برای بسیاری از توسعه‌دهندگان یک چالش در پایه‌های کد بزرگ باشد.

نسخه REST API

تغییرات API اجتناب‌ناپذیر است، اما نشانی‌های وب نقطه پایانی هرگز نباید باطل شوند یا برنامه‌هایی را که از آنها استفاده می‌کنند خراب می‌شوند.

API ها اغلب برای جلوگیری از مشکلات سازگاری نسخه می شوند. برای مثال، /2.0/user/123 جایگزین /user/123 می‌شود. هر دو نقطه پایانی جدید و قدیمی می توانند فعال باقی بمانند. متأسفانه، حفظ چندین API تاریخی ضروری است. نسخه‌های قدیمی‌تر در نهایت می‌توانند حذف شوند، اما این فرآیند نیاز به برنامه‌ریزی دقیق دارد.

REST API Authentication

API مسابقه نشان داده شده در بالا باز است: هر سیستمی می‌تواند بدون مجوز یک جوک دریافت کند. این برای APIهایی که به داده‌های خصوصی دسترسی دارند یا درخواست‌ها را به‌روزرسانی و حذف می‌کنند، قابل اجرا نیست.

برنامه‌های سمت کلاینت در همان دامنه با RESTful API کوکی‌ها را مانند هر درخواست HTTP دیگری ارسال و دریافت می‌کنند. (توجه داشته باشید که Fetch() در مرورگرهای قدیمی‌تر به اعتبارنامه گزینه init تنظیم شود.) بنابراین یک درخواست API می تواند برای اطمینان از ورود کاربر به سیستم و داشتن حقوق مناسب تأیید شود.

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

  • احراز هویت پایه HTTP . سرصفحه مجوز HTTP حاوی یک رشته نام کاربری:password با کدگذاری base64 در سرصفحه درخواست ارسال می‌شود.
  • کلیدهای API. یک برنامه شخص ثالث با صدور کلیدی که ممکن است حقوق خاصی داشته باشد یا محدود به یک دامنه خاص باشد، مجوز استفاده از API را دریافت می کند. کلید در هر درخواست در هدر HTTP یا در querystring ارسال می شود.
  • OAuth. قبل از هر درخواستی با ارسال شناسه مشتری و احتمالاً یک رمز مشتری به سرور OAuth، یک توکن به دست می آید. سپس رمز OAuth با هر درخواست API ارسال می شود تا زمانی که منقضی شود.
  • JSON Web Tokens (JWT). نشانه های تأیید هویت امضا شده دیجیتالی به طور ایمن در هر دو سربرگ درخواست و پاسخ منتقل می شوند. JWT ها به سرور اجازه می دهند تا حقوق دسترسی را رمزگذاری کند، بنابراین تماس با پایگاه داده یا سایر سیستم های مجوز لازم نیست.

تأیید هویت API بسته به زمینه استفاده متفاوت است:

  • در برخی موارد، یک برنامه شخص ثالث مانند سایر کاربران وارد شده با حقوق و مجوزهای خاص رفتار می شود. به عنوان مثال، یک API نقشه می‌تواند مسیرهای بین دو نقطه را به یک برنامه فراخوانی بازگرداند. باید تأیید کند که برنامه یک مشتری معتبر است اما نیازی به بررسی اعتبار کاربر ندارد.
  • در موارد دیگر، برنامه شخص ثالث داده های خصوصی را برای یک کاربر خاص مانند محتوای ایمیل درخواست می کند. REST API باید کاربر و حقوق او را شناسایی کند، اما ممکن است برای آن مهم نباشد که کدام برنامه API را فراخوانی می‌کند.

امنیت REST API

یک API RESTful مسیر دیگری را برای دسترسی و دستکاری برنامه شما فراهم می کند. حتی اگر یک هدف هک با مشخصات بالا نباشد، یک کلاینت بد رفتار می‌تواند هزاران درخواست در هر ثانیه ارسال کند و سرور شما را خراب کند.

امنیت فراتر از محدوده این مقاله است، اما بهترین شیوه های رایج عبارتند از:

    • از HTTPS استفاده کنید
    • از یک روش احراز هویت

قوی استفاده کنید

  • از CORS برای محدود کردن تماس‌های سمت سرویس گیرنده به دامنه‌های خاص استفاده کنید
  • حداقل عملکرد را ارائه دهید — یعنی گزینه های DELETE را که لازم نیست ایجاد نکنید
  • تمام نشانی‌های وب نقطه پایانی و داده‌های بدنه را اعتبارسنجی کنید
  • از افشای نشانه های API در جاوا اسکریپت سمت سرویس گیرنده اجتناب کنید
  • دسترسی از دامنه‌های ناشناخته یا آدرس‌های IP را مسدود کنید
  • مسدود کردن بارهای غیرمنتظره بزرگ
  • محدود کردن نرخ را در نظر بگیرید — یعنی درخواست‌هایی که از همان کد API یا آدرس IP استفاده می‌کنند به N در دقیقه محدود می‌شوند
  • با یک کد وضعیت HTTP مناسب پاسخ دهید و سربرگ در حافظه پنهان
  • درخواست‌ها را ثبت کنید و خرابی‌ها را بررسی کنید

درخواست های متعدد و داده های غیر ضروری

API های RESTful با اجرای آنها محدود می شوند. ممکن است یک پاسخ حاوی داده‌های بیشتری از نیاز شما باشد، یا درخواست‌های بیشتری برای دسترسی به همه داده‌ها لازم باشد.

یک API RESTful را در نظر بگیرید که دسترسی به داده‌های نویسنده و کتاب را فراهم می‌کند. برای نمایش داده‌های 10 کتاب پرفروش، مشتری می‌تواند:

  • 10 جزئیات /book/ را که بر اساس تعداد فروش‌ها مرتب شده‌اند (اول فروشنده برتر) درخواست کنید. پاسخ شامل فهرستی از کتاب ها با شناسه هر نویسنده است.
  • حداکثر 10 درخواست /author/{id} برای واکشی جزئیات هر نویسنده ارسال کنید.

این به عنوان مشکل N+1 شناخته می‌شود. N درخواست API باید برای هر نتیجه در درخواست والد انجام شود.

اگر این یک مورد معمول است، RESTful API را می توان تغییر داد تا هر کتاب بازگردانده شده حاوی جزئیات کامل نویسنده مانند نام، سن، کشور، بیوگرافی و غیره باشد. حتی می‌تواند جزئیات کامل کتاب‌های دیگر آنها را ارائه دهد – اگرچه این می‌تواند به میزان قابل توجهی بار پاسخ را افزایش دهد!

برای جلوگیری از پاسخ‌های غیرضروری بزرگ، API را می‌توان تنظیم کرد تا جزئیات نویسنده اختیاری باشد – برای مثال، ?author_details=full. تعداد گزینه‌هایی که نویسندگان API باید به آن‌ها پاسخ دهند می‌تواند گیج‌کننده باشد.

منبع: https://iransite.com

نوشته های مرتبط:

مدیر سایت

https://adskg.ir/

Related Posts

کاشت مو به روش طبیعی

مدیر سایت

طرز تهیه ماکارونی ساده بدون هیچی | غذای نوستالژی ایرانی

مدیر سایت

سیگنال ارز دیجیتال

مدیر سایت