برنامه های کاربردی نرم افزار از بسیاری جهات زندگی ما را آسان تر و بهتر کرده اند. ما تقریباً هر روز از آنها استفاده می کنیم و برخی افراد بیشتر از تعامل با سایر افراد از برنامه ها استفاده می کنند.

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

Web API چیست؟

Web API ها نوعی از API هستند که برای استفاده در وب طراحی شده اند. به عبارت دیگر، برنامه‌های کاربردی، سیستم‌ها و سرویس‌های نرم‌افزاری مبتنی بر وب از Web API برای تبادل اطلاعات از طریق اینترنت استفاده می‌کنند. آنها درخواست ها را ارسال می کنند و پاسخ ها را دریافت می کنند، معمولاً در قالب هایی مانند JSON یا XML.

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

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

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

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

رویکردهایی برای توسعه APIهای وب

API های وب را می توان با استفاده از روش های مختلف بر اساس نیازها توسعه داد. در اینجا چند رویکرد متداول دنبال می شود:

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

SOAP - پروتکل دسترسی به اشیا ساده از XML برای تبادل اطلاعات به روشی ساختاریافته استفاده می کند.

GraphQL – برای پرس و جو و دستکاری API ها استفاده می شود.

gRPC - یک چارچوب فراخوانی از راه دور که از HTTP/2 برای انتقال اطلاعات استفاده می کند.

در بخش‌های آینده، طراحی و توسعه APIها را تحلیل می‌کنیم و بر روی REST APIها به عنوان پروتکل مرکزی بحث خود تمرکز می‌کنیم.

درک الزامات و اهداف

در هر فرآیند توسعه نرم افزار، درک الزامات و موارد استفاده مورد نظر قبل از شروع بسیار مهم است. این به شما کمک می کند هزینه، زمان و سایر منابع مورد نیاز پروژه را برنامه ریزی و تخمین بزنید.

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

تعریف منابع و نقاط پایانی

REST API ها حول منابع می چرخند، که نهادهایی هستند که داده ها یا اشیاء را در سیستم نشان می دهند. هر منبع توسط یک URI منحصر به فرد به نام شناسه منبع شناسایی می شود. این منابع را می‌توان از طریق نقاط پایانی ، که URL‌های خاصی هستند که درخواست‌های مشتری را دریافت و پردازش می‌کنند، دسترسی و دستکاری کرد.

بهترین روش‌ها پیشنهاد می‌کنند که از اسم‌ها برای منابع در نقاط پایانی به جای افعالی استفاده کنید که ممکن است عملیات روی منبع را نشان دهند.

مثال زیر را در نظر بگیرید: https://api.example.com/products

نقطه پایانی از بهترین روش استفاده از یک اسم برای منبع (در این مورد، products ) پیروی می کند. توجه کنید که چگونه از شکل جمع - محصولات استفاده کردم؟ همچنین اگر با مجموعه ای از اشیاء کار می کنید، توصیه می شود از جمع استفاده کنید.

با این حال، نقطه پایانی زیر https://api.example.com/add-product توصیه نمی‌شود، زیرا از یک فعل استفاده می‌کند و سعی می‌کند عملی را در منبع توصیف کند. این رویکرد می تواند برای عملیات پیچیده تر پیچیده شود.

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

به عنوان مثال: https://api.example.com/categories/{categoryId}/products/{productId} .
در اینجا، نقطه پایانی را تعریف می کنیم که سلسله مراتب واضحی را بین category و منابع product حفظ می کند.

استفاده از روش های HTTP و کدهای وضعیت

در REST API ها از HTTP برای ارتباط بین کلاینت و سرور استفاده می شود. HTTP متدهای استانداردی دارد که عمدتاً برای انجام عملیات روی منابع استفاده می شود. در زیر فهرست ی از این روش ها به همراه اهداف آنها آورده شده است:

GET - جزئیات منبع را واکشی کنید. این جزئیات توسط سرور در بدنه پیام پاسخ بازگردانده می شود.

POST - یک منبع جدید ایجاد کنید. جزئیات منبعی که باید ایجاد شود در بدنه پیام درخواست ارسال می شود.

PUT - بسته به در دسترس بودن یک منبع، ایجاد یا به روز رسانی کنید. جزئیات منبعی که باید ایجاد یا به روز شود در بدنه پیام درخواست ارسال می شود.

حذف - یک منبع را حذف کنید.

PATCH - یک منبع را تا حدی به روز کنید. تغییراتی که باید در منبع ایجاد شود در بدنه پیام درخواست ارسال می شود.

رویکرد توصیه شده برای ایجاد یک REST API کاملاً تعریف شده، استفاده صحیح از این روش‌های HTTP برای انجام عملیات CRUD (ایجاد، خواندن، به‌روزرسانی، حذف) مربوطه در منبع است. همچنین، باید مطمئن شوید که API با کد وضعیت HTTP مناسب در بدنه پیام پاسخ به مشتری پاسخ می دهد.

کدهای وضعیت نتیجه نهایی یک درخواست را منعکس می کنند. در زیر برخی از کدهای رایج وضعیت HTTP وجود دارد که می توانید استفاده کنید:

200 باشه

201 ایجاد شد

204 بدون محتوا

400 درخواست بد

401 غیر مجاز

403 ممنوع

404 یافت نشد

500 خطای سرور داخلی

سرویس 503 در دسترس نیست

504 Gateway Timeout

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

استراتژی های نسخه سازی

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

حفظ نسخه‌های مختلف باعث می‌شود API‌های شما با گذشته سازگار باشند و به مشتریان این امکان را می‌دهد که از نسخه ترجیحی API بر اساس نیاز خود استفاده کنند. گزیده‌ای از این وبلاگ آموزنده در وب‌سایت Postman توضیح می‌دهد که چه زمانی نسخه‌سازی API شما ایده‌آل است:

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

نسخه API را می توان به روش های مختلفی انجام داد. در اینجا چند روش وجود دارد:

نسخه URI : شماره نسخه را در مسیر URL قرار دهید. به عنوان مثال، https://api.example.com/v1/products .

Query Parameter Versioning : شماره نسخه را به عنوان پارامتر پرس و جو در URL مشخص کنید. برای مثال، https://api.example.com/products?version=1 .

نسخه هدر : شماره نسخه را در هدرهای HTTP درخواست قرار دهید. به عنوان مثال، استفاده از یک هدر سفارشی مانند X-API-Version: 1 .

Content Negotiation : نسخه را در هدر Accept درخواست مشخص کنید که اغلب از انواع رسانه استفاده می کند. برای مثال، Accept: application/vnd.example.v1+json .

Embedded Versioning : شماره نسخه را در نوع رسانه پاسخ جاسازی کنید. برای مثال application/vnd.example.product-v1+json .

ملاحظات امنیتی

یکی دیگر از جنبه های مهمی که باید در هنگام توسعه API در نظر گرفت امنیت است. در اینجا چند نکته کلیدی برای یادآوری وجود دارد:

برای رمزگذاری اطلاعات رد و بدل شده بین مشتری و سرور، HTTPS را پیاده سازی کنید.

احراز هویت و مجوز را پیاده سازی کنید تا اطمینان حاصل کنید که فقط کاربرانی که دارای امتیازات مناسب هستند می توانند عملیات روی منابع را انجام دهند. روش های متداول عبارتند از: احراز هویت پایه، احراز هویت حامل یا توکن، JWT و OAuth 2.0. همچنین، کنترل دسترسی مبتنی بر نقش را برای مدیریت دسترسی به منابع پیاده سازی کنید.

برای جلوگیری از حملات آسیب‌پذیری مانند SQL injection و Cross-Site Scripting (XSS) اعتبارسنجی ورودی و پاکسازی را پیاده‌سازی کنید.

برای کنترل تعداد درخواست‌هایی که یک کلاینت می‌تواند به سرور در یک بازه زمانی خاص ارائه کند، محدودیت‌های نرخ و throttling را پیاده‌سازی کنید. این به جلوگیری از بارگذاری بیش از حد روی سرور کمک می کند.

مستندات

یکی از جنبه های کلیدی اما اغلب نادیده گرفته شده در توسعه API مستندسازی است. بسیار مهم است که API خود را مستند کنید تا کاربران ویژگی ها و عملکردهای آن را درک کنند.

مستندات باید جامع، آسان برای درک و پیروی از شیوه های استاندارد باشد. شامل نمونه‌هایی از بدنه‌های درخواست و پاسخ، کدهای وضعیت HTTP استفاده‌شده، و موارد دیگر. برای توصیف RESTful API های خود می توانید از مشخصات Open API پیروی کنید.

استراتژی های مرتب سازی، فیلتر کردن و صفحه بندی

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

برای رفع این مشکل، باید مرتب سازی و فیلتر کردن رکوردها را فعال کنید. همچنین باید صفحه بندی را برای شکستن تعداد رکوردهای واکشی شده پیاده سازی کنید و محدودیتی برای ناوبری و پردازش آسان تر تعیین کنید.

نظارت بر استفاده، ثبت و سلامت

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

نتیجه گیری

APIها، به ویژه Web APIها، برای برنامه های کاربردی نرم افزاری برای برقراری ارتباط از طریق اینترنت ضروری هستند.

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

اگر این مقاله برای شما جالب بود، به راحتی می توانید مقالات دیگر من را در freeCodeCamp تحلیل کنید و با من در لینکدین ارتباط برقرار کنید.

خبرکاو