تکنولوژی نوین اینترنتی
الیه! بحث Versioning در API یکی از مفاهیم مهم توی طراحی API حرفهای هست، مخصوصاً وقتی داری یه API عمومی یا بزرگ برای مدت طولانی توسعه میدی. چون با گذشت زمان، احتمال اینکه نیاز به تغییر در ساختار یا رفتار API داشته باشی خیلی زیاده — و نمیخوای این تغییرات برنامهی کلاینتهایی که قبلاً به API وصل شدن رو بشکنه.
در ادامه یه راهنمای کامل از versioning توی API (مخصوصاً در لاراول) برات آوردم:
وقتی تغییراتی توی API بدی (مثل تغییر ساختار خروجی، حذف فیلدها، تغییر نام مسیرها)، بهتره نسخهی جدیدی از API ایجاد کنی که با نسخههای قبلی تداخلی نداشته باشه.
سادهترین و رایجترین روش:
مزایا:
قابل فهم برای همه
سازگار با مرورگر
لاگگیری و دیباگ راحتتر
مزایا:
URL تمیز میمونه
مناسب برای APIهای پیشرفته و RESTful
معایب:
برای تست در مرورگر یا ابزار ساده سختتره
کمتر توصیه میشه، چون semantically درست نیست و امنیت/قابلیت کش پایینتری داره.
ساخت فایل Route مخصوص نسخه:
RouteServiceProvider
:
برای هر نسخه، مسیرها و کنترلرهای جداگانه تعریف کن.
نسخههای قدیمیتر رو تا زمانی که کاربران ازشون استفاده میکنن پشتیبانی کن.
بهتره نسخهها فقط در صورت تغییر breaking تغییر کنن (یعنی تغییراتی که با نسخه قبلی سازگار نیستن).
از مستندسازی نسخهها غافل نشو — برای هر نسخه بهتره مستندات جداگانه تهیه کنی.
Laravel API Resources: برای مدیریت خروجی JSON با فرمت خاص
Laravel Passport / Sanctum: احراز هویت در APIهای نسخهدار
Swagger / Laravel Scribe: مستندسازی اتوماتیک نسخههای مختلف API
اینجا یه پروژه ساده API با نسخهبندی v1
و v2
بر پایه Laravel میسازیم، با قابلیت احراز هویت (API Token) و خروجی JSON ساختارمند.
✅ API نسخهبندی شده (/api/v1
و /api/v2
)
✅ احراز هویت با Laravel Sanctum
✅ دو کنترلر برای مدیریت کاربران در هر نسخه
✅ خروجی JSON با Resource
✅ Routing مرتبشده با namespace
اضافه کردن middleware به app/Http/Kernel.php
:
routes/api.php
:
routes/api_v1.php
:
routes/api_v2.php
:
app/Http/Controllers/Api/V1/UserController.php
app/Http/Controllers/Api/V2/UserController.php
routes/api.php
):
POST /api/register
→ دریافت توکن
در درخواستهای GET /api/v1/user
یا GET /api/v2/user
، هدر زیر رو اضافه کن: