Motoshub · REST API v1 · Bridge Framework · branch: moto-next

API نسل جدید موتوشاب: چه داریم، چه نداریم، و نقشه‌ی مهاجرت

پلاگین ow_plugins/api یک لایه‌ی REST تمیز (سبک Laravel روی فریم‌ورک Bridge) با JWT و RBAC و Swagger زنده است — اما تا امروز فقط ۵ دامنه به آن منتقل شده. این سند دقیقاً می‌گوید چه چیزی هست، چه چیزی باید ساخته شود، و با چه تمپلیتی.

24
عملیات زنده روی v1
5
دامنه‌ی منتقل‌شده
~20+
دامنه‌ی باقی‌مانده
168
op منطق آماده در گیت‌وی قدیمی
این سند مکملِ سند معماری و نقشه‌راه کلی محصول است — آن‌جا تصویر بزرگ (multi-tenant، Django، SSO)، این‌جا تمرکز روی مهاجرت API.

01 چه API‌هایی الان روی v1 داریم؟

استخراج مستقیم از spec زنده‌ی motonext.shub.ir/api/v1/docs/json — ۲۴ عملیات، ۵ دامنه.

دامنهعملیاتEndpointهاوضعیت
Auth3POST /v1/auth/login · GET /v1/auth/me · GET /v1/auth/permissionsکامل
Blogs5GET · POST · GET/{id} · PATCH/{id} · DELETE/{id}CRUD
News5GET · POST · GET/{id} · PATCH/{id} · DELETE/{id}CRUD
Photos5GET · POST · GET/{id} · PATCH/{id} · DELETE/{id}CRUD
Albums6CRUD + GET /v1/albums/{id}/photosCRUD+
نکته‌ی کلیدی: این v1 با گیت‌وی قدیمی iismobilesupport (همان ۱۶۸ عملیاتِ mobile/services/…) فرق دارد. آن‌جا منطق کسب‌وکار همه‌ی فیچرهای اجتماعی از قبل نوشته شده (در سرویس‌های BOL اکسوال). پس مهاجرت یعنی «بسته‌بندی همان منطق موجود در تمپلیت تمیز v1» — نه نوشتن از صفر.

02 تمپلیت «Bridge» — الگویی که باید تکرار شود

هر فیچر دقیقاً از این پنج قطعه ساخته می‌شود (نمونه: Blog).

Request
اعتبارسنجی+sanitize
Controller
API/V1 + OA + Route
Service
(interface)
Oxwall BOL
منطق موجود

و خروجی از Resource عبور می‌کند؛ دسترسی با Policy کنترل می‌شود.

// ow_plugins/blogs/src/Http/Controllers/API/V1/BlogController.php
#[Policy(BlogPolicy::class)]
class BlogController extends ApiController {
  public function __construct(private BlogServiceInterface $blogService){ parent::__construct(); }

  #[OA\Get(path:'/v1/blogs', tags:["Blogs"], ...)]  //  داکس Swagger زنده
  #[RouteGet('api/v1/blogs', middleware:['auth.jwt'])] //  روت + JWT
  #[RoutePermissions(['blogs.view','blogs.list'])]    //  RBAC
  public function index(BlogListRequest $request){
    $blogs = $this->blogService->fetchBlogs(true, $request->validated());
    return Response::json(BlogResource::collection($blogs));
  }
  // show() / store() / update() / destroy() به همین شکل …
}

Controller نازک است: فقط orchestration. کارِ واقعی در Service، اعتبارسنجی در Request، شکل خروجی در Resource.

قطعهمسیرمسئولیت
Controllersrc/Http/Controllers/API/V1/روت‌ها (attribute)، داکس OA، فراخوانی سرویس
Requests (List/Store/Update)src/Http/Requests/پراپرتی تایپ‌دار + #[Required]/#[Sanitize]/#[StripTags] + schema
Resourcesrc/Http/Resources/تبدیل خروجی به JSON یکدست + respondCreated/Updated/Deleted
Service (+Interface)src/Services/ + Contracts/Services/منطق؛ به BOL اکسوال وصل می‌شود
Policysrc/Policies/مجوز دسترسی به عملیات
ثبتSwaggerController scanDirs + auto-routeافزودن پوشه‌ی پلاگین به اسکنر داکس
نکته‌ی محیط: این لایه از Attributeهای PHP 8 و سینتکس مدرن استفاده می‌کند (مثل new Generator()->generate()) — یعنی نیازمند PHP 8+ است، برخلاف هسته‌ی اکسوال که روی PHP 7.4 است. این واگرایی نسخه را باید در استقرار مدیریت کرد.

03 چه چیزی نداریم و باید بسازیم؟

سه سطل: منتقل‌شده ، منطق آماده برای بسته‌بندی ، و نبودِ کامل بک‌اند 🆕.

سطل اصلی — منطق در گیت‌وی قدیمی هست، فقط باید در تمپلیت v1 بسته‌بندی شود

دامنهop قدیمیمنبع منطقتخمین
Users / Profile42iismobilesupport + BOL_UserService۵–۸ روز
Groups (+ فایل/پوشه)28groups + iisgroupsplus۴–۶ روز
Messaging / Chat13mailbox۴–۵ روز
Events12event + iiseventplus۳–۴ روز
Forum12forum + iisforumplus۳–۴ روز
Newsfeed9newsfeed + iisnewsfeedplus۳–۴ روز
Notifications6notifications۲ روز
Comments5BOL_CommentService۲ روز
Questions / Polls5iisquestions۲ روز
Video4video (الگوی photo آماده)۱–۲ روز
Friends4friends۲ روز
Search / Mention / Privacy / Flag / Contact~6پلاگین‌های مربوطه۲–۳ روز
iispors (پرسمان‌ساز/کوییز)~82iispors + iispors_judgement۱۰–۱۵ روز
Landing builder~10iislandingcreator۳ روز

🆕 سطل دوم — بک‌اند اصلاً وجود ندارد (فقط در پروتوتایپ mock است)

ماژول سازمانیوضعیتمسیر پیشنهادی
Projects / Contracts / Funds / Research / Reportsنه بک‌اند، نه APIساخت جدید — ترجیحاً روی Django (به سند معماری کلی)، یا پلاگین جدید اکسوال با همین تمپلیت
این‌ها «امکانات فعلی موتوشاب» نیستند — در بک‌اند PHP هیچ اثری ندارند. پس در «مهاجرت API» نمی‌گنجند؛ یک خط کاری جداگانه‌ی «ساخت از صفر» هستند. اگر هدف کوتاه‌مدت است، می‌شود موقتاً به‌عنوان پلاگین اکسوال با همین تمپلیت ساختشان؛ اگر بلندمدت و مقیاس‌پذیر، روی Django.

04 فرایند ساخت یک API جدید (قدم‌به‌قدم)

برای هر دامنه‌ی ، این چرخه تکرار می‌شود. مثال: افزودن Video.

  1. در پلاگین مقصد (مثلاً ow_plugins/video) پوشه‌های src/Http/Controllers/API/V1، Requests، Resources، Services، Contracts/Services، Policies را بساز.
  2. Service: یک VideoServiceInterface + VideoService که داخلش همان متدهای منطقیِ موجود در web_service_video.php / BOL را صدا می‌زند (منطق را کپی نکن، فراخوانی کن).
  3. Requests: VideoListRequest/StoreRequest/UpdateRequest با پراپرتی‌های تایپ‌دار و اعتبارسنجی.
  4. Resource: VideoResource برای شکل خروجی یکدست.
  5. Controller: متدهای index/show/store/update/destroy با attributeهای #[OA\...]، #[Route...('api/v1/videos', middleware:['auth.jwt'])] و #[RoutePermissions(...)].
  6. Policy برای مجوزها؛ ثبت permissionها.
  7. پوشه‌ی پلاگین را به scanDirs در SwaggerController اضافه کن تا در داکس زنده ظاهر شود.
  8. تست: در Swagger UI (/api/v1/docs/index) عملیات جدید را try-it-out کن.
چرا سریع است: چون منطق در BOL موجود است و تمپلیت تثبیت‌شده، بعد از دو-سه دامنه‌ی اول، هر CRUD ساده عملاً «کپی و تطبیق» می‌شود. بخش زمان‌بر، دامنه‌های بزرگ (Users، Groups، iispors) است که سطح عملیات بالایی دارند.

05 نقشه‌ی مهاجرت فازبندی‌شده

به‌ترتیب ارزش برای فرانت و وابستگی‌ها. تخمین برای یک بک‌اند سینیور.

فاز A
هسته

کاربر، دوستان، اعلان‌ها

Users/Profile (۴۲ op)، Friends، Notifications. بدون این‌ها هیچ صفحه‌ی واقعی‌ای در فرانت زنده نمی‌شود. ~۹–۱۲ روز.

فاز B
اجتماعی

گروه، فید، کامنت، چت

Groups (+files)، Newsfeed، Comments، Messaging. قلب تعامل اجتماعی. ~۱۳–۱۷ روز.

فاز C
محتوا

رویداد، فروم، ویدیو، نظرسنجی، جستجو

Events، Forum، Video، Questions، Search/Privacy/Flag. ~۱۱–۱۵ روز. (Blog/News/Photo از قبل )

فاز D
تخصصی

پرسمان‌ساز و لندینگ

iispors + judgement (بزرگ، ~۸۲ op) و Landing builder. ~۱۳–۱۸ روز.

فاز E
جدید

ماژول‌های سازمانی (خط کاری موازی)

Projects/Contracts/Funds/Research/Reports — ساخت از صفر (Django یا پلاگین جدید). مستقل از A–D پیش می‌رود.

جمع تقریبی فازهای A تا D (بسته‌بندی امکانات موجود): حدود ۴۶ تا ۶۲ روزِ کاری مهندسی خالص برای یک نفر (~۲.۵ تا ۳ ماه). با تیم دو نفره و موازی‌سازی دامنه‌ها، عملاً کمتر. فاز E جداگانه و بزرگ‌تر است.

06 یک تصمیم که با تو است

درباره‌ی داکسِ فرانت که در جلسه‌ی قبل شروع شده بود.

قبل از این‌که بفهمیم api/v1 منبع اصلی است، قرار بود openapi.json گیت‌وی موبایل (۱۶۸ op) را بازتولید و روی گیت‌هاب پروتوتایپ (docs.shub.ir/docs) پوش کنم. حالا دو منبع داکس داریم:

پیشنهاد: فرانت‌اند بر روی api/v1 هدف‌گذاری شود و مهاجرت مطابق فازهای فوق پیش برود؛ تا وقتی یک دامنه هنوز روی v1 نیامده، فرانت موقتاً از گیت‌وی موبایل همان دامنه استفاده کند. به‌همین‌دلیل داکسِ گیت‌وی موبایل را پوش نکردم و منتظر تصمیم تو ماندم. اگر بخواهی، همان را هم به‌عنوان «مرجع موقت» منتشر می‌کنم.


Motoshub API v1 · تهیه‌شده پس از خواندن پلاگین api و اسپک زنده‌ی motonext.shub.ir · branch moto-next