یکپارچهسازی موفق فقط ارسال درخواست HTTP نیست؛ قرارداد داده، احراز هویت، مدیریت خطا، تکرار امن، مانیتورینگ و مالکیت سرویس باید از ابتدا مشخص شوند.
پیش از کدنویسی چه چیزهایی روشن شود؟
- مالک هر داده و منبع حقیقت.
- رویدادی یا زمانبندیشده بودن تبادل.
- حجم، فرکانس و سقف درخواست.
- محیط آزمایش و داده نمونه.
- سیاست نسخهبندی و تغییر قرارداد.
قرارداد داده
نام فیلد، نوع، اجباریبودن، قالب تاریخ، شناسه یکتا و معنی وضعیتها باید مستند باشد. نمونه موفق کافی نیست؛ نمونه خطا، مقدار خالی و سناریوهای مرزی نیز لازم است. قرارداد بهتر است قابل آزمون خودکار باشد.
امنیت اتصال
احراز هویت متناسب با ریسک انتخاب میشود: کلید API، OAuth، امضای درخواست یا گواهی متقابل. اسرار نباید در کد یا گزارشها ذخیره شوند. محدودیت IP بهتنهایی جایگزین هویت و سطح دسترسی نیست.
مدیریت خطا و تکرار امن
قطع موقت شبکه نباید باعث گمشدن یا دوبارهکاری تراکنش شود. استفاده از شناسه یکتای درخواست، صف، Retry با فاصله افزایشی و Dead Letter Queue برای جریانهای حساس ضروری است. خطاهای قابل تکرار باید از خطاهای دادهای جدا شوند.
مانیتورینگ و تحویل
- نرخ موفقیت و زمان پاسخ.
- تعداد صف و خطاهای تکرارشونده.
- هشدار بر اساس اثر کسبوکار.
- شناسه رهگیری مشترک میان سامانهها.
- Runbook بازیابی و مسئول پاسخ.
در پایان، مستند API، مجموعه تست، اطلاعات محیطها و سناریوی پشتیبانی باید تحویل شود.
پرسشهای متداول
Webhook بهتر است یا Polling؟
اگر سرویس مبدا رویداد قابل اعتماد ارائه کند Webhook معمولاً سریعتر است؛ Polling برای سازگاری یا کنترل دورهای کاربرد دارد.
چطور ارسال تکراری را کنترل کنیم؟
با Idempotency Key، شناسه کسبوکار یکتا و ثبت وضعیت پردازش در مقصد.
