عملیات VPN را پیش از مقایسه APIها تعریف کنید
کنترل اتصال، تأمین پروفایل، مدیریت کاربران و مشاهده، APIهای متفاوتی هستند. نخست شیء، کنش و شرط موفقیت را نام ببرید.
یک صفحه محصول می‌گوید API دارد، و جلسه یکپارچه‌سازی روی پرسش دوم متوقف می‌شود. کدام عملیات، روی کدام شیء، توسط چه کسی فراخوانی می‌شود، و چه چیزی موفقیت شمرده می‌شود؟ پاسخ به این چهار پرسش پیش از مقایسه محصولات معمولاً نیمی از گزینه‌ها را حذف می‌کند. همچنین مقایسه باقیمانده را به چیزی تبدیل می‌کند که یک آزمون می‌تواند تعیین کند.
ادعای داشتن API را با یک عملیات جایگزین کنید
API یک حامل است، نه یک قابلیت. نقطه پایانی REST، سوکت محلی و پوشش خط فرمان همگی می‌توانند API نامیده شوند، و آنها عملیات هم‌ارز ارائه نمی‌دهند.
پیش از باز کردن مستندات، عملیات را در قالب یک جمله بنویسید.
شروع یک اتصال محلی کنشی سمت کلاینت است که کاربری پیش روی آن است. صدور پروفایل دستگاه کنش تأمین است که انبارگردانی پشت آن است. غیرفعال کردن دسترسی کاربر کنش اداری است که رد حسابرسی دارد. این سه معمولاً در اجزای متفاوت، متعلق به تیم‌های متفاوت و با اختیار متفاوت زندگی می‌کنند.
چهار فیلد که قرارداد را آزمون‌پذیر می‌کند
برای هر عملیات چهار فیلد را پر کنید: شیء، کنش، فراخوان و شرط موفقیت. قراردادی که یک فیلد کم دارد، آرزوست.
جدول تمام کاربرگ است:
| Field | Question | Example |
|---|---|---|
| Object | What is being acted on? | One enrolled device |
| Action | Observe, create, change, start, stop, or revoke? | Revoke |
| Caller | Which identity calls it? | Deployment service |
| Success | What observable state proves it? | Future sign-in denied |
شرط موفقیت همان فیلدی است که افراد از آن می‌گذرند، و همان است که تعیین می‌کند یکپارچه‌سازی کار می‌کند یا نه. تنظیم ذخیره‌شده تونل فعال نیست، و حساب غیرفعال‌شده نشست پایان‌یافته نیست.
اگر دو عملیات به فراخوان‌های متفاوت نیاز دارند، دو یکپارچه‌سازی هستند. گنجاندن آنها در یک حساب سرویس معمولاً به معنای دادن اختیاری بیش از نیاز هر یک است.
رابط را با لایه واقعی‌اش هماهنگ کنید
رابط مدیریت اجتماعی OpenVPN از طریق TCP یا سوکت Unix با یک دیمن گفتگو می‌کند. فرمان‌های آن شامل مشاهده وضعیت و سیگنال به دیمن است.
این آن را کانال کنترل دیمن می‌کند، نه API اشتراک میزبانی‌شده و نه سرویس ثبت‌نام کاربران. خواندن دقیق مستنداتش شما را از ساختن روی لایه‌ای که مالک شیء نیست بازمی‌دارد.
همان مستندات می‌گوید پروتکل رمزنگاری خودش را ندارد. هر کس به سوکت برسد می‌تواند دیمن را کنترل کند، پس با آن به‌عنوان کنترل حساس رفتار کنید نه جریان سنجه‌ها. آن را به loopback یا سوکت Unix ببندید، و اگر فراخوان دور به آن نیاز دارد، پشت ترتیبی محدود قرار دهید. افشای آن در اینترنت برای راحتی، کانال کنترل را به رخداد تبدیل می‌کند.
رفتار پس از فراخوانی را مشخص کنید
پذیرش همانند تکمیل نیست. دیمن ممکن است پیش از بالا آمدن تونل بازگردد، پس منتظر رویداد مستند تکمیل یا شکست بمانید و آن را به درخواستی که فرستادید گره بزنید.
تصمیم بگیرید فراخوان در صورت گم شدن پاسخ چه می‌کند. تکرار کورکورانه یک ساخت یا اتصال مجدد همانند بررسی این نیست که آیا درخواست نخست اثر کرده است.
حذف دسترسی دست‌کم سه کنش متفاوت است: مسدود کردن ورود آینده، پایان دادن به نشست فعال، و باطل کردن اعتبارنامه. آن‌هایی را بخواهید که سیاست واقعاً می‌طلبد، و در قرارداد بگویید کدام کدام است. بدون شواهد، یک به‌روزرسانی موفق حساب را باطل‌سازی کامل نخوانید. این تفاوت در هنگام رخداد، وقتی ساعت می‌گذرد، اهمیت دارد.
قرارداد را با یک پایلوت بررسی کنید
یک پایلوت کوچک تأییدشده باید موفقیت، رد، وقفه و تلاش مجدد را پوشش دهد، و سپس عملیات برنامه‌ای که قرار است مجاز یا ممنوع باشد.
برای رابطی در سطح دیمن، دو فرمان مشاهده و یک سیگنال را تمرین می‌کنند:
echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505فقط اختیاری را بدهید که عملیات می‌طلبد. رازها را از گزارش‌های روزمره بیرون نگه دارید و جزئیات خصوصی کافی ثبت کنید تا بگویید کدام هدف تحت تأثیر قرار گرفت و چگونه پایان یافت.
مسیر بازیابی را برای حالتی بنویسید که خود API کنترل از کار افتاده است. رابطی را انتخاب کنید که مالک شیء و چرخه عمر آن است؛ ادعاهای خودکارسازی روی یک صفحه محصول جایگزین نیستند.