همیشه در زمان تغییر API ها نیاز داشتیم که بتوانیم نسخه قبلی را نگه داریم و تغییرات را در نسخه جدیدی عرضه کنیم تا مصرف کنندگان API بتوانند فرصتی برای سوئیچ به نسخه جدید داشته باشند. در این آموزش این کار را خواهیم کرد.
در دنیای امروز، API ها همه جا هستند. از برنامه تجاری شما گرفته تا فروشگاه آنلاین بهترین دوست شما، تا کتری هوشمند شما که قهوه را از آن برنامه کاربردی در تلفن شما درست می کند. همه چیز باید در نقطه ای با چیز دیگری صحبت کند، و اینجاست که به عنوان مهندسان نرم افزار، ما به دنبال یک API هستیم. ما از آنها برای ارسال به روز رسانی ها به کتری شما یا ارائه کاتالوگ محصولات برای فروشگاه آنلاین یا یک نقطه ورود به انبوه داده هایی که برنامه تجاری شما ممکن است به آن نیاز داشته باشد استفاده می کنیم.
در طول ده سال گذشته APIها بیش از پیش به یک ضرورت تبدیل شده اند، زیرا وب موبایل نیاز به برنامه ها و وب سایت های سریعتر را معرفی کرده است. این بدان معناست که به عنوان مهندسان نرم افزار، ما باید به دنبال راه هایی برای ارائه سریع داده ها برای این برنامه ها و وب سایت ها در صورت درخواست باشیم - به جای باز شدن برنامه یا صفحه. برای درک بهتر این انتقال، میتوانید به تاریخچه APIها و چگونگی ایجاد انقلابی در نحوه ساخت و تعامل ما با نرمافزارها بپردازید.
با گذشت زمان، APIهای ما از نظر پیچیدگی افزایش مییابند، از نظر عملکردهایی که ارائه میدهند رشد میکنند، و ردپای دادههایی که آنها میگیرند هر چند وقت یکبار تغییر میکند. اینجاست که نسخهسازی API میتواند به شما در مدیریت رشد و تغییرات در برنامهتان کمک کند، همانطور که طبق معمول پیش میروید.
برای مثال، اگر یک API برای یک کتری هوشمند ارائه کنید، تغییرات در API شما میتواند به این معنا باشد که 100 یا 1000 نفر از مردم به طور ناگهانی نمیتوانند فنجان قهوه صبح خود را درست کنند. یا مردم نمی توانند از آن فروشگاه آنلاین تسویه کنند و در نتیجه فروش کاهش می یابد. رویداد دریافت نکردن اطلاعات صحیح یا بهروز از برنامه کسبوکار شما، منجر به تصمیمهای نادرست و احتمال از دست دادن سرنخها میشود.
همانطور که می توانید تصور کنید، نسخه بندی نکردن API خود به درستی می تواند تأثیر مخربی بر تجارت یا محصول شما داشته باشد.
اما چگونه باید API خود را نسخه کنید؟
چه رویکردهایی وجود دارد؟ آیا حتی نیاز به نسخه API خود دارید؟ شاید شما یک برنامه داخلی داشته باشید که از یک API استفاده می کند که فقط گروه کوچکی از افراد در نقش مهم غیر تجاری از آن استفاده می کنند، آیا هنوز نیاز دارید که API خود را نسخه کنید؟ بیایید به این سؤالات و موارد دیگر نگاه کنیم.
نسخه API چیست ؟
بنابراین قبل از شروع، بیایید به این بپردازیم که دقیقاً نسخه API چیست. این رویکردی است که ما به عنوان مهندسان نرم افزار از آن برای ایجاد تغییرات در API خود استفاده می کنیم، به همین سادگی است. ممکن است بخواهیم نحوه ساختار دادهها یا نحوه عملکرد عملکرد را تغییر دهیم یا لایههای مجوز اضافی برای افزایش امنیت در مناطقی که نادیده گرفته شدهاند اضافه کنیم. روشهای دیگری نیز وجود دارد که میتوانیم برای انجام برخی از این وظایف استفاده کنیم، مانند کنترل دسترسی مبتنی بر نقش یا پرچمهای ویژگی. با این حال، معمولاً میخواهیم از اینها در کنار نسخهسازی API خود استفاده کنیم تا کنترل دقیقی را که برای برنامه خود میخواهیم به دست آوریم.
بیایید سناریوی کتری هوشمند را در نظر بگیریم. ممکن است کتری دیگری منتشر کنیم که از همان API استفاده میکند و میخواهد آب را به دمای متفاوتی گرم کند. محصول اولیه ما آب را تا 100 درجه گرم می کند تا یک قهوه درست کند، اما از بازخورد محصول با مشتریان ما - محصول ما بیشتر توسط چای خورهایی استفاده می شود که فقط می خواهند آب را تا 80 درجه گرم کنند تا یک فنجان چای عالی بسازند. این به خودی خود شاید یک مقاله جداگانه در مورد تهیه یک فنجان چای عالی باشد. محصول اولیه ما از نسخه 1 API ما استفاده می کرد که فقط به شما اجازه می دهد آب را تا 100 درجه گرم کنید. ما میتوانیم این را اصلاح کنیم و دمای پیشفرض 100 درجه را اضافه کنیم، اما این اجازه نمیدهد برای کاربرانی که آن گزینه را میخواهند، سفارشیسازی اضافه کنیم.
اگر نسخهسازی را در API خود پیادهسازی کنیم، انتشار محصول جدید ما میتواند با انتشار نسخه جدیدی از API ما هماهنگ شود - به همه کتریهای جدید اجازه میدهد مستقیماً با نقاط پایانی جدید مورد نیاز صحبت کنند. سپس میتوانیم بهروزرسانیهای محصولات قدیمیمان را بهروزرسانی کنیم تا آنها را برای استفاده از API جدیدتر ارتقا دهیم - عملکرد جدید را به همه مشتریان دارای محصول پشتیبانیشده ارائه کنیم. به مشتریانی که محصولات پشتیبانینشدهاند اجازه میدهند همچنان از محصول مانند همیشه استفاده کنند. داشتن این سطح از سازگاری یکپارچه به این معنی است که مشتریان ما بهترین تجربه را با نام تجاری ما خواهند داشت - احتمال بازگشت آنها را در آینده افزایش می دهد.
اگر API خود را نسخهبندی نکنیم یا این سطح از نقش را با استفاده از یک API نسخهسازی شده برنامهریزی کنیم - در نهایت میتوانیم وفاداری و اعتماد مشتری را نسبت به خود از دست بدهیم. در حالی که ممکن است این یک مورد شدید از عدم نسخهسازی API شما باشد، این یک واقعیت است که واقعاً ممکن است این اتفاق بیفتد. حتی اگر برنامهای فوری برای عرضه محصولات اضافی یا تغییر عملکرد ندارید - آیا میخواهید بعداً وقتی میخواهید آن ویژگی عظیم جدید را اضافه کنید، نگران این موضوع باشید یا ویژگی عظیمی را که به رشد شما کمک کرد تغییر دهید. پایگاه کاربر برای شروع؟