روزی شیخ با ناراحتی تمام بر مکتب خانه آمد و گفت : چه خبرررتونه؟؟ چه خبرتونه؟؟؟؟؟؟
مریدان همه قفل کردند و یکی به آرامی گفت : یا شیخ چرا آمپر چسباندی!!!؟؟؟
شیخ گفت: امروز برای مشاوره به استارت آپی رفته بودم!API طراحی کرده بودند که افتضاح بودن را به لول جدیدی رسانده بود.
بنشینید که بروم روی منبر که خدای ناکرده شما از این اشتباهات بچه گانه نکنید.البته بگویم طراحی یک API خودش یک درس 5 واحدی میباشد!این چیز هایی که گویم در حداصول اولیه است!
1- کمی ثبات داشته باشید!
رنگ و وارنگ آدرس گذاری نکنید. یک مدل را در پیش گرفته و مطابق همان پترن ادامه بدهید.
در نام گذاری ها یک قانون را درپیش گرفته مانند snake_case
یا تمام نام ها جمع باشد یا تمام نام ها مفرد ! هرکس هرچی تو حالش بود.نباشد! یا GET /users و یا GET /user
حواستان به مسائل authentication و authorization باشد
از http-headerها استفاده کنید!کنتور نمی اندازد به مولا!
از http-status-code ها استفاده کنید ( مورد داشتیم همه را 200 بر میگردانده و فقط پیام آن فرق میکرده)
از methods ها درست استفاده کنید نه اینکه RESTful بنویسید اما DELETE ها همهGET باشد!
2- تمام api ها باید محافظت شده باشند و تعدادی public شوند نه اینکه همه public باشند و تعدادی محافظت بشن!
3- چه میکروسرویس و لودبالانسر دارید و چه ندارید حتما /healthداشته باشید! کارش این است که حال واحوال API را گزارش میکند!
4- ورژن بزنید آقا!ورژن بزنید، بخدا شاخ نمیزند ! بلکه فردا روزی اگر API تغییر کرد! کلاینت بدبخت یکهو قفل نکند!مثل آدم کارش را بکند نهایت بهش تایم میدهید که آپدیت کند!
5- برای تاکید دوباره از HTTP status codes استفاده کنید.نه اینکه اینطور باشد که همیشه نتیجه OK باشد و شما فقط پیام را تغییر دهید!
6- از HTTP methods استفاده کنید! مورد داریم که با GET عمل DELETE را انجام میدهد!چه وضعشه!حال برای یاد آوری :
a. GET برای خواندن داده
b. POST برای نوشتن داده ای که وجود ندارد
c. Patch برای آپدیت بخشی از داده ها
d. Put برای کلا جایگزین کردن داده ها با داده جدید
e. DELETE هم برای حذف آن
7- قشنگ منطقی آدرس ها طراحی کنید!
مثلا GET /users بهتر است یا GET /getusers یا مثلا GET /deleteuser/{id} یا DELETE /user/{id}
8- به کاربر بنده خدا قشنگ بفهمانید که کجا را اشتباه فرستاده! الحمد الله همه یاد گرفته اند می نویسند "خطایی رخ داده . با مدیر تماس بگیرید" خب اگه من به اون مدیر دسترسی داشتم که از خجالتش در میامدم(یاد سیستم ناد که برای دانشگاه ما بود افتادم)
9- حدالامکان اپدیت ها را Patch طراحی کنید!یعنی سعی کنید که کل داده ها را باهم آپدیت نکنید!
10- آقا در دیتابیس یا سرور Pageکنید، حسش را ندارید همه را می فرستید فرانت که چی!!!!فردا روز را هم فکر کنید! ردیف ها زیاد شد که دیگر فرانت خونش جاری میشود!عبدالباقی طور پروژه نسازید.
11- اگر شما از دیتابیس های کاردرست مثل SQL Server یا Oracle استفاده میکنید دلیل بر این نیست که ول کنید به امان خدا!همان هم نیاز به طراحی و افزایش پرفرمنس دارد!(الحمد الله که لایسنس در جای ما معنی ندارد اگر خودم شخصا کوچ میکردم به Postgres البته دارم یادش میگیرم هاااا، شاخ که نمیزند)
مریدان که از مطالب کیف کرده بودند رو به خوش خط مکتب کردند و گفتند : نوشتی! وی گفت نه! عکس میگیرم! مریدان گفتند از چه؟؟؟و در اینجا بود که وی فهمید که .......
