Rest API چیست؟ معرفی کامل و کاربردهای آن

اگر به دریافت اطلاعات از منبع دیگری در اینترنت مانند توییتر یا Github فکر کرده باشید، احتمال زیادی وجود دارد که با عبارت REST API برخورد کنید. اما REST API چیست؟ چه کاری می تواند برای شما انجام دهد؟ چطور باید از آن استفاده کرد؟ 

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

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

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

API REST چیست؟

فرض کنید در حال تلاش برای یافتن ویدیوهای مربوط به بتمن در یوتیوب هستید. یوتیوب را باز می‌کنید، «بتمن» را در قسمت جستجو تایپ می‌کنید، اینتر را فشار می‌دهید و فهرستی از ویدیوهای مربوط به بتمن را می‌بینید. یک REST API به روشی مشابه کار می کند. شما چیزی را جستجو می کنید و لیستی از نتایج را از سرویسی که از آن درخواست می کنید دریافت می کنید.

API یک رابط برنامه نویسی کاربردی است. این مجموعه قوانینی است که به برنامه ها اجازه می دهد با یکدیگر صحبت کنند. توسعه دهنده API را روی سرور ایجاد می کند و به کلاینت اجازه می دهد تا با آن ارتباط برقرار کند.

REST تعیین می کند که API چگونه به نظر می رسد. مخفف "Representational State Transfer" است. این مجموعه قوانینی است که توسعه دهندگان هنگام ایجاد API خود از آنها پیروی می کنند. یکی از این قوانین بیان می کند که وقتی به یک URL خاص پیوند می دهید، باید بتوانید بخشی از داده (به نام منبع) را دریافت کنید.

هر URL یک درخواست نامیده می شود در حالی که داده هایی که به شما ارسال می شود پاسخ (Response) نامیده می شود.

آناتومی یک درخواست Request

مهم است بدانید که یک درخواست از چهار چیز تشکیل شده است:

نقطه پایان endpoint
متد
headers
داده (یا body)

نقطه پایانی (یا مسیر) نشانی اینترنتی است که درخواست می‌کنید. از این ساختار پیروی می کند:

root-endpoint/?

root-endpoint نقطه شروع API است که از آن درخواست می کنید. نقطه پایانی API Github https://api.github.com است در حالی که API root-endpoint توییتر https://api.twitter.com است.

مسیر منبعی را که درخواست می‌کنید مشخص می‌کند. مانند یک منشی تلفنی خودکار فکر کنید که از شما می خواهد برای سرویسی 1، برای سرویس دیگر 2، برای سرویس دیگری 3 و غیره را فشار دهید.

همانطور که می توانید به بخش هایی از یک وب سایت پیوند دهید، می توانید به مسیرها دسترسی داشته باشید. به عنوان مثال، برای دریافت لیستی از همه پست‌های برچسب‌گذاری شده تحت "جاوا اسکریپت" در آنوفل، به https://anophel.com/tag/javascript برای مثال می روید. https://anophel.com root-endpoint  این است و /tag/javascript مسیر است.

یک مثال REST API

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

{
  "response_code": 0,
  "results": [
    {
      "category": "Science: Computers",
      "type": "multiple",
      "difficulty": "easy",
      "question": "What does GHz stand for?",
      "correct_answer": "Gigahertz",
      "incorrect_answers": [
        "Gigahotz",
        "Gigahetz",
        "Gigahatz"
      ]
    }
  ]
}

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

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

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

REST API و بقیه

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

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

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

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

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

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

برای مثال :

یک درخواست GET به /user/ لیستی از کاربران ثبت شده در یک سیستم را برمی گرداند
یک درخواست POST به /user/ یک کاربر با آی دی 123 با استفاده از داده های body ایجاد می کند. پاسخ id را برمی گرداند.
یک درخواست PUT به user/123/ کاربر 123 را با داده های body بروز می کند.
یک درخواست GET به user/123/ جزئیات کاربر 123 را برمی گرداند.
درخواست DELETE به user/123/ کاربر 123 را حذف می کند.

3. HTTP headers. هدرهای HTTP اطلاعاتی مانند توکن های احراز هویت یا کوکی ها را می توان در هدر درخواست HTTP قرار داد.
4. Body data. داده‌ها معمولاً در body HTTP به روشی مشابه با ارسال‌های <form> یا با ارسال یک رشته داده کدگذاری شده با JSON منتقل می‌شوند.

پاسخ API REST

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

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

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

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

REST API مثال “Hello word”

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

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

{
  "name": "restapi",
  "version": "1.0.0",
  "description": "REST test",
  "scripts": {
    "start": "node ./index.js"
  },
  "dependencies": {
    "express": "4.18.1"
  }
}

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

// simple Express.js RESTful API
'use strict';

// initialize
const
  port = 8888,
  express = require('express'),
  app = express();

// /hello/ GET request
app.get('/hello/:name?', (req, res) =>
  res.json(
    { message: `Hello ${req.params.name || 'world'}!` }
  )
);

// start server
app.listen(port, () =>
  console.log(`Server started on port ${port}`);
);

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

{
  "message": "Hello world!"
}

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

{
  "message": "Hello everyone!"
}

درخواست های REST سمت کلاینت و CORS

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

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>REST test</title>
</head>
<body>
<script>
fetch('http://localhost:8888/hello/')
  .then((response) => {
    return response.json();
  })
  .then((json) => {
    console.log(json);
  });
</script>
</body>
</html>

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

با این حال، فرض کنید سرویس وب RESTful شما اکنون به صورت live در دامنه /http://mydomain.com/hello در وب قرار داده شده است. URL صفحه JavaScript fetch بر این اساس تغییر کرده است، اما باز کردن /http://localhost:8888در مرورگر اکنون خطای کنسول Cross-Origin Request Blocked را برمی گرداند.

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

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

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

// /hello/ GET request
app.get('/hello/:name?', (req, res) =>
  res
    .append('Access-Control-Allow-Origin', '*')
    .json(
      { message: `Hello ${req.params.name || 'world'}!` }
    )
);

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

// enable CORS
app.use((req, res, next) => {
  res.append('Access-Control-Allow-Origin', '*');
  next();
});

// /hello/ GET request
// ...

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

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

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

چالش های REST API

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

Endpoint Consensus

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

1. user/123/
2. user/id/123/
3. user/?id=123/

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

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

REST API Versioning

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

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

احراز هویت در REST API

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

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

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

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

احراز هویت API بسته به زمینه استفاده متفاوت خواهد بود:

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

امنیت API REST

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

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

1. از HTTPS استفاده کنید
2. از یک روش احراز هویت قوی استفاده کنید
3. از CORS برای محدود کردن تماس های سمت کلاینت به دامنه های خاص استفاده کنید
4. حداقل عملکرد را ارائه دهید - یعنی گزینه های DELETE را که مورد نیاز نیستند ایجاد نکنید
5. تمام URL های نقطه پایانی و داده های body را تأیید کنید
6. از افشای توکن های API در جاوا اسکریپت سمت سمت کلاینت خودداری کنید
7. دسترسی از دامنه های ناشناخته یا آدرس های IP را مسدود کنید
8. محموله های غیرمنتظره بزرگ را مسدود کنید
9. محدود کردن rate را در نظر بگیرید - یعنی درخواست‌هایی که از همان نشانه API یا آدرس IP استفاده می‌کنند به N در دقیقه محدود می‌شوند
10. با کد وضعیت HTTP مناسب و هدر حافظه پنهان پاسخ دهید
11. درخواست ها را ثبت کنید و خرابی ها را بررسی کنید

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

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

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

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

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

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

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

آیا GraphQL API های REST را رفع می کند؟

معمای REST فیس بوک را به ایجاد GraphQL سوق داد . زبان جستجوی وب سرویس. آن را به عنوان SQL برای سرویس های وب در نظر بگیرید: یک درخواست مشخص می کند که به چه داده هایی نیاز دارید و چگونه می خواهید بازگردانده شوند.

GraphQL برخی از چالش های ایجاد شده توسط API های RESTful را برطرف می کند، اگرچه برخی دیگر را معرفی می کند. به عنوان مثال، کش کردن پاسخ های GraphQL دشوار می شود.

بعید است که کلاینتان شما مشکلاتی مشابه فیس بوک داشته باشند، بنابراین ممکن است ارزش آن را داشته باشد که GraphQL را زمانی که یک API RESTful فراتر از محدودیت های عملی خود تکامل می دهد، در نظر بگیرید.

لینک های REST API و ابزارهای توسعه

ابزارهای متعددی برای کمک به توسعه API RESTful در همه زبان ها وجود دارد. گزینه های قابل توجه عبارتند از:

1. Swagger: ابزارهای مختلفی برای کمک به طراحی، مستندسازی، ساختگی، آزمایش و نظارت بر REST APIها
2. Postman: یک برنامه تست API RESTful
3. Hoppscotch: یک جایگزین منبع باز و مبتنی بر وب برای Postman

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

1. Any API
2. لیست API
3. API های عمومی
4. Google APIs Explorer

سعی کنید قبل از اجرای سرویس های وب خود، برخی از API های RESTful را در پروژه های خود مصرف کنید. یا با ساختن یک API RESTful خود، جای پای فیسبوک، گیت هاب، گوگل و بسیاری از غول های دیگر را دنبال کنید.

نتیجه

ما در این مقاله با RestAPI آشنا شدیم و فهمدیم که برای اینکه بخواهیم از آن استفاده کنیم چه مواردی را باید در نظر بگیریم. امیدوارم این مقاله به شما کمک کرده باشد تا در مورد REST APIها به اندازه کافی بیاموزید و بتوانید هنگام ایجاد برنامه های خود از آنها به راحتی استفاده کنید.

شما در چه مواردی از RestAPI استفاده کرده اید؟ تجربه شما از آن چیست؟