دروازه API چه کاری انجام میدهد و چه وقت لازمش دارید؟
وقتی چند سرویس دارید، هر کدام باید بداند چطور کاربر را احراز هویت کند، چطور جلوی درخواست بیش از حد را بگیرد، و چطور خودش را به بیرون معرفی کند. اگر هر سرویس اینها را جدا انجام دهد، همان منطق چند بار نوشته میشود و دیر یا زود نسخههایش با هم فرق میکنند.
دروازه API این کارهای مشترک را جلو میکشد و در یک نقطه انجام میدهد.
کارهایی که به آن سپرده میشود
احراز هویت. توکن یک بار اینجا بررسی میشود و سرویسهای پشت آن، هویت را بهعنوان یک واقعیت میگیرند. این تنها دلیلی است که برای بیشتر سازمانها به تنهایی دروازه را توجیه میکند.
محدودیت نرخ. جلوگیری از اینکه یک مصرفکننده کل ظرفیت را بگیرد. برای APIی که به بیرون داده میشود، غیرقابل چشمپوشی است.
مسیریابی. کدام مسیر به کدام سرویس میرود. و مهمتر، امکان تغییر این نگاشت بدون اینکه مصرفکننده چیزی بفهمد — همان چیزی که مهاجرت تدریجی را ممکن میکند.
نسخهبندی. نگهداشتن نسخهٔ قدیمی API زنده در حالی که نسخهٔ جدید هم سرویس میدهد.
ثبت و پایش. یک نقطه که همهٔ ترافیک از آن رد میشود، بهترین جا برای دیدن اینکه چه کسی چه چیزی را چقدر صدا میزند.
تبدیل ساده. یکسانکردن قالب خطاها، افزودن شناسهٔ ردیابی، جمعکردن چند تماس در یکی برای مصرفکنندههای موبایل.
کجا لازم نیست
اگر یک سرویس دارید، دروازه یک پرش شبکهای اضافه است و چیزی به شما نمیدهد که همان سرویس نتواند خودش انجام دهد. این را زیاد دیدهایم: تیمی که هنوز یک برنامه دارد ولی دروازه گذاشته چون در معماریهای مرجع دیده بوده.
اگر همهٔ مصرفکنندههای شما داخلی و قابل اعتمادند و تعدادشان کم است، هم احتمالاً ارزشش را ندارد.
و اگر میخواهید منطق کسبوکار را در آن بگذارید — که وسوسهاش زیاد است — نگذارید. دروازهای که تصمیم کسبوکاری میگیرد، به یک نقطهٔ شکست تبدیل میشود که هیچ تیمی مالکش نیست و همه از تغییرش میترسند.
چیزی که با آن میآید و باید پذیرفت
یک نقطهٔ شکست مشترک. اگر دروازه بخوابد، همهچیز خوابیده. یعنی خودش باید افزونگی داشته باشد، و این هزینهای است که در برآورد باید دیده شود.
تأخیر اضافه. کم، ولی صفر نیست.
یک چیز دیگر برای نگهداری. پیکربندی، نسخه، و کسی که مسئولش باشد.
دو تصمیم که زود باید گرفته شوند
دروازه احراز هویت میکند یا سرویسها هم؟ پاسخ امن این است که هر دو: دروازه توکن را بررسی میکند و سرویسها هم فرض نمیکنند که هر درخواستی که به آنها میرسد از دروازه آمده. اگر سرویسی در شبکهٔ داخلی مستقیم قابل صدا زدن باشد و اعتماد کامل کند، یک دور زدن ساده کافی است.
سطح دسترسی کجا اعمال میشود؟ دروازه معمولاً میداند کاربر کیست، ولی نمیداند این کاربر حق دیدن این رکورد خاص را دارد یا نه. آن تصمیم متعلق به سرویس است. تقسیم درست: دروازه هویت را میگوید، سرویس اجازه را تعیین میکند.
اگر API را به بیرون میدهید
چند چیز که در APIی عمومی از روز اول لازم است و بعداً افزودنشان سختتر است:
کلید یا توکن بهازای هر مصرفکننده، تا بشود جلوی یکی را جدا گرفت.
محدودیت نرخ به تفکیک مصرفکننده، نه کلی.
قالب خطای یکسان و مستند.
و نسخهبندی از همان نسخهٔ اول. اگر API را بدون نسخه منتشر کنید، اولین تغییر ناسازگار یعنی شکستن همهٔ مصرفکنندهها — و در عمل یعنی هرگز تغییرش نمیدهید.
پیشنهاد عملی
با سادهترین چیزی که کار میکند شروع کنید. برای بیشتر سازمانها، یک وب سرور با پیکربندی درست بخش زیادی از این فهرست را میدهد و نیازی به محصول اختصاصی نیست.
سراغ دروازهٔ کامل وقتی بروید که تعداد سرویسها و مصرفکنندهها از حدی گذشت که نگهداشتن قواعد در چند جا سخت شد. و آن نقطه معمولاً دیرتر از چیزی میرسد که فکر میکنید.