What is an api?

مشخصا هر کسی که برنامه نویس باشه با API ها سر و کله زده اما بیایم ببینیم مفهوم API دقیقا چیه.

ای پی آی (API) یا Application Programming Interface به معنای واسط برنامه‌نویسی است. API یک مجموعه از توابع و روش‌های برنامه‌نویسی است که به توسعه‌دهندگان اجازه می‌دهد تا بتوانند از قابلیت‌ها و امکانات یک سامانه، برنامه یا سرویس دیگری استفاده کنند.

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

مشخصات اصلی API عبارتند از:

- تعریف یک سری قوانین برای تعامل بین سیستم‌ها یا اجزا

- تعریف ساختار داده‌ها، پارامترها و قالب‌های ارتباطی

- فراهم کردن توابع و متدها برای انجام کارهای مورد نیاز

- محافظت از بخش‌های داخلی سامانه از دسترس خارجی

- استانداردسازی روش تعامل بین برنامه‌ها

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

#API

@citax_tel

تو مصاحبه بک اند ممکنه بپرسن که آیا برای مایکروسرویس ها از API Gateway استفاده می کنید؟
مزیت ها و کاربرد های مختلف API

Gateway:
1. Routing
کلاینت فقط به یک endpoint درخواست میزنه و Gateway درخواست رو به مایکروسرویس مربوطه میده که دیزاین کلی سیستم ساده میشه

2. Rate limiting and throttling
می تونیم با اعمال Rate limiting جلوی حمله DDoS رو بگیریم و این موضوع در Gateway انجام بشه نه در هر مایکروسرویس

3. Caching
می تونیم پاسخ های هر مایکروسرویس رو Cache کنیم و اگر درخواست مشابه بود همون رو برگردونیم که بار کلی سیستم کم میشه

4. Authentication and Authorization می تونیم دسترسی دادن رو یکجا انجام بدیم تا اینکه هر مایکروسرویس جداگانه اینکار رو بکنه

5. Load Balancing
اگر از یک سرویس چند instance داشته باشیم می تونیم بینشون load balance کنیم

6. Monitoring
می تونیم یه سری metric جمع آوری کنیم و ببینیم کدوم مایکروسرویس ها ضعیف تر عمل میکنند و reliability سیستم رو بالا ببریم

7. Transformation
اگر مثلا یه سرویس SOAP قدیمی داشته باشیم که XML برمیگردونه می تونیم تبدیلش به JSON کنیم حتی میتونم داده های سرویس های مختلف رو ترکیب کنیم

8. Request and response
ولیدیشن اگر Schema از request و response مایکروسرویس ها داشته باشیم جایی که یک مایکروسرویس خطا خورده میتونیم متوجه بشیم و خطای مناسب برگردونیم

9. Circuit Breaker
با استفاده از این الگو اگر یک مایکروسرویس مشکلی داشت می تونیم از یک مایکروسرویس جایگزین استفاده کنیم

10. Service Discovery
کلاینت ها نیاز ندارن که بدونن هر مایکروسروس کجاست و با این الگو می تونیم راحت سرویس اضافه و کم کنیم

11. API Versioning Gateway
می تونه از وجود چند نسخه از یک API خبر داشته باشه و دولوپر ها راحت می تونن نسخه های جدید رو توسعه بدن

12. Error Handling
می تونیم خطا با فرمت یکسان تولید کنیم حتی اگر یک مایکروسرویس از دسترس خارج شده باشه

13. Service Aggregation
تو این الگو به جای اینکه یک کلاینت به چند مایکروسرویس درخواست بده، Gateway پاسخ چند مایکروسرویس رو تو یک response ترکیب می کنه که بار کلی سیستم کم میشه

14. Web Application Firewall (WAF)
می تونیم یک Firewall اضافه کنیم و جلوی حملاتی مثل XSS و DDoS و SQL Injection رو بگیریم

15. API Documentation
می تونیم تو Gateway با یک فرمت استادندارد مثل OpenAPI یا Swagger مستندات کلی سیستم رو تولید کنیم.

این مطالب همه تئوری هستند اما با استفاده از nginx می تونید اینها رو پیاده سازی کنید

link

#api_gateway

@Syntax_fa

✍️ Massimo Dev

🔵⚪️ نسخه‌بندی API یا API Versioning میدونی چیه؟

🚨 نسخه‌بندی API یه راه‌حلیه برای مدیریت تغییرات API در طول زمان بدون اینکه کاربرهای قدیمی دچار مشکل بشن. وقتی که API تغییر می‌کنه و ویژگی‌های جدیدی بهش اضافه می‌شه یا مشکلاتی برطرف می‌شن، نسخه‌بندی کمک می‌کنه تا کاربرهایی که از نسخه‌های قدیمی استفاده می‌کنن همچنان بدون مشکل به کارشون ادامه بدن و در عین حال نسخه‌های جدیدتر هم در دسترس باشن.

✳️ بذار یه مثال ساده بزنم:

فرض کن یه API داری که اطلاعات آب و هوا رو می‌ده. اولین نسخه‌ی API (v1) یه اندپوینت داره به اسم
/weather
که اطلاعات ساده‌ای مثل دما و رطوبت رو برمی‌گردونه.

نسخه 1 (v1):

GET /v1/weather?city=London
Result:
{
"temperature": "15°C",
"humidity": "75%"
}

بعداً تصمیم می‌گیری اطلاعات بیشتری مثل سرعت باد و پیش‌بینی هوا رو اضافه کنی. برای اینکه کاربرهای قدیمی دچار مشکل نشن، یه نسخه جدید از API (v2) معرفی می‌کنی:

نسخه 2 (v2):

GET /v2/weather?city=London
Result:
{
"temperature": "15°C",
"humidity": "75%",
"wind_speed": "10 km/h",
"forecast": [
{"day": "Monday", "temperature": "16°C"},
{"day": "Tuesday", "temperature": "17°C"}
]
}

به این ترتیب، کاربرهایی که از نسخه قدیمی (v1) استفاده می‌کنن همچنان بدون تغییر به کارشون ادامه می‌دن و کاربرهای جدید می‌تونن از ویژگی‌های جدید نسخه 2 (v2) استفاده کنن.

✳️ بهترین روش‌ها برای نسخه‌بندی API

🔹نسخه‌بندی URL:
- شماره نسخه رو توی مسیر URL قرار بده، مثل
/v1/resource
و
/v2/resource
- مثال:
GET /api/v1/weather،
GET /api/v2/weather.

🔹نسخه‌بندی با هدرها:
- از هدرهای سفارشی برای مشخص کردن نسخه استفاده کن.
- مثال:
GET /api/weather
با
headers: {"API-Version": "v2"}

🔹نسخه‌بندی با پارامترهای کوئری:
- شماره نسخه رو به عنوان پارامتر کوئری قرار بده.
- مثال:
GET /api/weather?version=2

🔹استراتژی پایان‌دهی به نسخه‌های قدیمی:
- به کاربرها بگو که نسخه قدیمی چه زمانی غیرفعال می‌شه و راهنمایی برای مهاجرت به نسخه‌های جدید بده.
- یه بازه زمانی مشخص و راهنمای مهاجرت ارائه کن.

🔹مستندسازی:
- برای هر نسخه از API مستندات واضح و دقیقی فراهم کن.
- مثال‌ها، موارد استفاده و راهنماهای مهاجرت رو توضیح بده.

🔹سازگاری با نسخه‌های قبلی:
- تا حد ممکن نسخه‌های جدید رو سازگار با نسخه‌های قبلی نگه دار تا کاربرها دچار مشکل نشن.
- از نسخه‌بندی معنایی (مثل major.minor.patch) استفاده کن تا سطح تغییرات رو نشون بدی مثلا نسخه ،29.5.0 شده 29.5.1

🔹سیاست نسخه‌بندی:
- یه سیاست نسخه‌بندی تعریف کن که مشخص کنه کی و چطور نسخه‌های جدید منتشر می‌شن.
- واضح بگو که چه زمانی تغییرات بزرگ نیاز به یه نسخه جدید دارن.

Source:
@gopher_academy

#api_versioning

@Syntax_fa