REST مخفف عبارت است انتقال دولت نمایندگی - توصیف تقریباً بی معنی از پر استفاده ترین فناوری خدمات وب! REST راهی است برای دو سیستم کامپیوتری برای ارتباط از طریق HTTP به روشی مشابه با مرورگرها و سرورهای وب.

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

این مقاله محبوب در سال 2020 به روز شد تا API های REST مدرن را به طور دقیق توضیح دهد. برای اطلاعات بیشتر در مورد REST API، بخوانید طراحی RESTful Web API با Node.js.

مثال REST

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

https://official-joke-api.appspot.com/jokes/programming/random

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

[ { "id": 29, "type": "programming", "setup": "There are 10 types of people in this world...", "punchline": "Those who understand binary and those who don't" }
]

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

curl "https://official-joke-api.appspot.com/jokes/programming/random"

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

REST و بقیه

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

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

1. سرور مشتری. SystemA یک درخواست HTTP را به یک URL میزبانی شده توسط SystemB می دهد که یک پاسخ را برمی گرداند.

   این شبیه به نحوه عملکرد یک مرورگر است. برنامه یک URL خاص را درخواست می کند. درخواست به یک وب سرور هدایت می شود که یک صفحه HTML را برمی گرداند. آن صفحه ممکن است حاوی ارجاعاتی به تصاویر، شیوه نامه ها و جاوا اسکریپت باشد که درخواست ها و پاسخ های بیشتری را به همراه دارد.

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

3. قابل ذخیره سازی. یک پاسخ باید به صورت کش تعریف شود یا نه.

4. لایه. مشتری درخواست کننده نیازی ندارد بداند که آیا با سرور واقعی، یک پروکسی یا هر واسطه دیگری در ارتباط است.

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

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

1. URL نقطه پایانی. برنامه‌ای که یک API RESTful را پیاده‌سازی می‌کند، یک یا چند نقطه پایانی URL را با دامنه، پورت، مسیر، و/یا querystring تعریف می‌کند - برای مثال، https://mydomain/user/123?format=json.

2. روش HTTP. روش‌های مختلف HTTP را می‌توان در هر نقطه پایانی که نقشه عملیات ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) برنامه را انجام می‌دهد، استفاده کرد:

   روش HTTP	چیز چندش و کثیف	عمل
   شو	خواندن	داده های درخواستی را برمی گرداند
   پست	ایجاد	رکورد جدیدی ایجاد می کند
   PUT یا PATCH	به روز رسانی	یک رکورد موجود را به روز می کند
   حذف	حذف کردن	یک رکورد موجود را حذف می کند

   مثال:

   • یک درخواست GET به /user/ لیستی از کاربران ثبت شده در یک سیستم را برمی گرداند
   • یک درخواست POST به /user/123 یک کاربر با شناسه ایجاد می کند 123 با استفاده از داده های بدن
   • یک درخواست PUT به /user/123 کاربر را به روز می کند 123 با داده های بدن
   • یک درخواست GET به /user/123 مشخصات کاربر را برمی گرداند 123
   • یک درخواست DELETE به /user/123 کاربر را حذف می کند 123

3. هدرهای HTTP. اطلاعاتی مانند توکن های احراز هویت یا کوکی ها را می توان در هدر درخواست HTTP قرار داد.

4. داده های بدن. داده ها معمولاً در بدنه HTTP به روشی مشابه HTML منتقل می شوند <form> ارسالی یا با ارسال یک رشته داده کدگذاری شده با JSON.

پاسخ

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

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

سایر هدرهای HTTP را می توان تنظیم کرد از جمله حافظه پنهان or تاریخ انقضا دستورالعمل هایی برای تعیین مدت زمانی که می توان یک پاسخ را قبل از در نظر گرفتن در حافظه پنهان نگه داشت بیات.

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

REST "Hello World" مثال

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

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

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

دویدن npm install از خط فرمان برای واکشی وابستگی ها، سپس یک ایجاد کنید 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}`);
);

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

{ "message": "Hello world!"
}

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

{ "message": "Hello everyone!"
}

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

صفحه HTML زیر را در نظر بگیرید که در یک مرورگر در URL راه اندازی شده است 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>

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

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

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

خوشبختانه، اشتراک منابع متقابل (CORS) به ما اجازه می دهد تا از این محدودیت امنیتی دور بزنیم. تنظیم یک Access-Control-Allow-Origin هدر پاسخ HTTP به مرورگرها می گوید که این درخواست را مجاز می دانند. می توان آن را به یک دامنه خاص یا * برای همه دامنه ها (انجام شده توسط Joke 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 می‌تواند هدر را به هر درخواست نقطه پایانی اضافه کند:

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

چالش های REST

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

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

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

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

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

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

نسخه API

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

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

تصدیق

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

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

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

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

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

دوربین های مداربسته

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

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

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

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

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

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

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

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

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

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

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

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

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

برای کثیف کردن دستان خود با طراحی REST API، توصیه می کنیم طراحی RESTful Web API با Node.js. با جاوا اسکریپتی که قبلاً می شناسید شروع به ساخت APIهای کاربردی کنید.

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

• سوگگر: ابزارهای مختلفی برای کمک به طراحی، مستندسازی، ساختگی، آزمایش و نظارت بر REST APIها
• پستچی: یک برنامه تست API RESTful
• پست زن: یک جایگزین متن باز و مبتنی بر وب برای Postman.

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

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

منبع: https://www.sitepoint.com/developers-rest-api/?utm_source=rss