رابط برنامه نویسی نرم افزار یا API

در ابتدا فقط میخوام مفهموم API رو به زبان ساده توضیح بدم.

حتما تاالان UI یا user interface به گوشتون خورده، ui یا رابط کاربری درواقع رابطی گرافیکی برای تعامل بهتر انسان با کامپیوتره ینی مثلا همین که فلان دکمه زیبا که اگه روش کلیک کنی فلان کارو میکنه.

خب پس UI رابطی هست برای تعامل انسان با برنامه های کامپیوتری و حالا برای اینکه برنامه های کامپیوتری بتونن باهم ارتباط برقرار کنن هم به یک رابط نیاز داریم .

نه صبر کنین مگه برنامه ها هم باهم ارتباط دارن؟

بله برای مثال شما گوگل مپ رو درنظر بگیرید که حجم زیادی دیتا دراختیار داره حالا گوگل مپ میگه اجازه دارین از دیتاهای من در application خوتون استفاده کنین و منِ توسعه دهنده حالا میخوام از این دیتا توی application خودم استفاده کنم برای اینکار باید از یه رابط استفاده کنم که به اون aplication programming interface یا رابط برنامه نویسی نرم افزار میگیم.

خب API انواع مختلفی داره مثل API سخت افزاری ، API سیستم عاملی ، API زبان های برنامه نویسی ، API تحت وب (وب سرویس)که من دراین مقاله فقط درموردAPIتحت وب صحبت میکنم.

هر وب سرویس یک API هست، به این خاطر که به بوسیله وب سرویس می تونیم امکانات و داده های یک نرم افزار رو به اشتراک بزاریم، اما یک API لزوماً یک Web Service نیست.

درواقعWeb Service منابعی هستن که در محیط اینترنت دردسترس قرار میگیرن.

مثال هایی از API تحت وب:

1.لاگین کردن به وب سایت های مختلف با حساب های گوگل

2.استفاده از قابلیت جستجوی گوگل در وب سایت شخصیتون

3.نمایش نقشه گوگل در وب سایت ها

همش شد گوگل که ، انگار گوگل داره دنیارو میگیره :)

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

انواع وب سرویس ها:

1.RPC

این اصطلاح مخفف واژگان remote Procedure Client است. این نوع وب سرویس در دو نوع مدل XML-RPC و JSON-RPC عرضه شده است و همان‌طور که از نام آن‌ها مشخص است، مدل اول از فرمت اکس‌ام‌ال پشتیبانی می‌کند و مدل دوم از جیسون (نیاز به توضیح است که این وب سرویس امروزه کاربرد چندانی ندارد.)

2.REST

این اصطلاح که مخفف واژگان Representational State Transfer است بر خلاف موارد قبل یک پروتکل حساب نمی‌شود بلکه نوعی معماری است که نسبت به بقیه کاربرد آسان‌تری دارد و به همین دلیل هم هست که امروزه فراگیر شده است.سرویسی که بر پایه این معماری نوشته شده باشد را Restful API گویند.

3.GraphQL

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

انتخاب بین REST و GraphQL:

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

نقاط ضعف REST:

1. Multiple Endpoints (Multiple Round Trips)

در سرویس های rest هر route یا به عبارتی هر url دیتای خاصی را به عنوان response نشان می دهد. پس هر url تنها به یک سورس از اطلاعات دسترسی دارد و می تواند همان موارد را در خروجی نشان دهد و برای دسترسی به داده های مختلف نیاز است تا urlهای مختلفی را تعریف کنید.

2. Overfetching/Underfetching Data (ارسال و دریافت دیتا)

در طول یک پروژه داده هایی را که مورد نیازتان است از URLهایی برای دریافت این داده ها استفاده می کنید که شاید بخشی از داده هایی که به واسطه آن URL در اختیارتان قرار می گیرد مورد نیازتان نباشد و اینکه دیتایی که دریافت می کنید تمام دیتای مورد نیازتان نباشد و مجیور باشید از چندین URL برای دریافت آن استفاده کنید که درنهایت باعث میشه که دیتای سنگینی دریافت کنید و همچنین زمان بیشتری برای response صرف میشود.

3. API Versioning

روشی است که به شما کمک می کند تا درصورتی که در response داده های خود تغییری ایجاد کنید کاربرانی که از نسخه های قبلی استفاده می کنند دچار مشکل نشوند و همچنان بتوانند از سرویس های مختلف استفاده کنند.ولی همیشه این مشکل وجود دارد که وقتی شما یک ورژن جدید از API را منتشر می نمایید دیگر از نسخه های قدیمی پشتیبانی نمی کنید و در نهایت کاربران باید این بروزرسانی را مورد استفاده قرار دهند و مشکل اصلی زمانی به وجود می آید که شما موظفید برای ورژن جدید URLها، داکیومنت و … جدید را بنویسید و البته در نهایت دچار یک افزونگی کد می شوید.

4. Weak Typing

هر زمان که داده ای را از سرویس RESTFULL دریافت می کنید حتما این اتفاق می افتد که به داده خاصی که مد نظرتان است دسترسی نداشته باشید و دلیل آن این است که شما یکسری URLهای خاص را برای طیف خاصی از داده در نظر گرفته اید و برای اینکه به داده های خاصی از سرویس RESTFULL دسترسی داشته باشید باید یک فرآیند پیچیده از URLها و ساختارهای وابسته به آن را پشت سر بگذارید.

5. Client Kept In The Dark

باید همیشه این موضوع را در نظر داشته باشید در کنار پیاده سازی ساختارهای پیچیده پیاده سازی URLها و به عبارتی end-point ها مختلف کاربر هیچگاه اطلاعی از داده ای که دریافت می کند ندارد مگر اینکه از url استفاده کرده و داده ای که برای وی ارسال می شود را دریافت نماید و این در مواقعی باعث بروز مشکل می شود می توانم بگویم این احتمال وجود دارد که داده ای که کاربر دریافت می کند تمام ان چیزی که به آن نیاز دارد نیست.

درمقابل ضعف های REST ، مزایای GraphQL قرار دارند:

1. One Request To Get Them All

سرویس GraphQL ساختاری را در اختیارتان قرار می دهد تا بتوانید تنها با استفاده از یک end-point تمام داده ای که نیاز دارید را از طریق یک query درخواست کنید .

2. Strongly Typed:

به دلیل ساختاری که GraphQL دارد از انواع مختلف داده ای پشتیبانی می کند چه آنهایی که در ساختار آن وجود دارد و چه آنهایی که کاربر آنها را مشخص می کند.باید بدانید که هیچگونه وابستگی به این که باید نوع داده ای را برای آن مشخص کنید ندارد و در صورتی که داده ای را درخواست می کنید می داند که چه نوع داده ای را باید response کند.

3. Client Is The Driver :

در GraphQL این امکان به توسعه دهنده فرانت اند داده میشود تا خودش مشخص کند که چه داده و با چه نوع داده ای را می خواهد به عنوان response دریافت کند.این ویژگی باعث می شود تا ارسال و دریافت داده هایی که مورد نیاز کاربر نیست به حداقل برسد.

4. API Evolution :

گراف کیوال مطابق با schema که برای آن مشخص شده است داده مورد نیاز کاربر را response می کند درنتیجه به راحتی می توانید فیلدی را کم و یا زیاد کنید پس نیاز به ورژن های مختلف از API از بین می رود.

5. Transport Layer Agnostic :

یکی از اصلی ترین ویژگی های GraphQL که باعث تمایز آن از REST می شود این است که از پروتکل های انتقال دیتای مختلفی را پشتیبانی می کند اگر وب سرور API به جهت پورتکل انتقال دیتا تغییراتی داشته باشد (http, https, WebSocket, TCP, UDP) انگاه GraphQL می تواند داده را با توجه به پورتکل انتقال بین client و server جا­به‌­جا کند.

معایب GraphQL:

1. Non-Existent Caching

گراف کیوال برخلاف REST که از سیستم کش HTTP استفاده می کند از cach پشتیبانی نمی کند.

2. Monitoring and Error Reporting :

سیستم RESTFUl از status های HTTP برای مدیریت انواع خطاها استفاده می کند.این مقوله باعث میشود تا بتوان بحث مانیتورینگ را بر روی API به راحتی پیاده سازی نمود.ولی API که توسط ساختار GraphQL پیاده سازی شده است همه responseها را با status 200 ارسال می کند.و این کار مانیتوریگ API را با مشکل مواجه می کند.

3. Exposed Schema and Resource Attacks :

برخلاف REST در GraphQL برای درخواست از Queryها استفاده می کنید در نتیجه باید به درستی با Schema دادها آشنایی داشته باشید بنابراین وقتی API خود را در اختیار دیگران قرار می دهید این API را باید آنقدر قوی و ایمن توسعه داده باشید تا کاربر در حالی که با Queryها کار می کند نتواند به راحتی به دیتا استراکچر (Schema) دسترسی داشته باشد و حملات Dos را انجام دهد.

4. Security – Authentication and Authorization :

مشکلی که در APIهایی که با GraphQL توسعه داده می شود در حال حاضر در بین جامعه GraphQL وجود دارد این است که چگونه باید مقوله امنیت را پیاده سازی کرد. این درحالی است که هنوز استانداردی برای ادغام authentication and authorization وجود ندارد.

5. Young Ecosystem :

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

در انتها باید بگم که GraphQL درسرعت و راحتی و پرفورمنس واقعا برتری داره و کاررو برای توسعه دهنده فرانت اند خیلی راحتتر میکنه ، اما REST امنیت بیشتری داره.

-اگر این مقاله برای شما مفید بود در انتشار آن کوتاهی نکنید:)

شیوا توکل | 23 بهمن 98