ساختار حساب فرعی
ساختار URL پلتفرم شما محرک اصلی برای ساختار حساب‌های فرعی شما و به‌طور خاص‌تر اینکه قسمت site_uri چگونه باید باشد، است.
انواع مختلف ساختارهای سایتی که AFP پشتیبانی می کند را در زیر ببینید:
| مورد استفاده | ساختار URL | مقدار فیلد site_uri در API | مقدار فیلد request_id در API |
|---|---|---|---|
| زیر دامنه ها | ریشه:https://littlepig.example.comمحتوا: https://littlepig.example.com/food.html | littlepig.example.com | littlepig (یا یک شناسه منحصر به فرد داخلی مرتبط با کاربر) |
| پوشه های فرعی | ریشه:https://example.com/littlepigیا https://example.com/sites/littlepigمحتوا: https://example.com/littlepig/food.htmlیا https://example.com/sites/littlepig/food.html | example.com/littlepigیا example.com/sites/littlepig | littlepig (یا یک شناسه منحصر به فرد داخلی مرتبط با کاربر) |
| ترکیبی از زیر دامنه ها و پوشه های فرعی | ریشه:https://sites.example.com/sites/littlepigمحتوا: https://sites.example.com/sites/littlepig/food.html | sites.example.com/sites/littlepig | littlepig (یا یک شناسه منحصر به فرد داخلی مرتبط با کاربر) |
| URL های فردی | ریشه (یا نمایه سازنده):https://example.com/user/littlepigمحتوا: https://example.com/nf8ag4n | example.com/user/littlepigمهم: برای این مورد، ما علاوه بر این نیاز داریم که متا تگ "Platform Author" در همه صفحات وجود داشته باشد. | littlepig (یا یک شناسه منحصر به فرد داخلی مرتبط با کاربر) |
اگر کاربران شما دارای چندین ویژگی در پلتفرم شما هستند، چگونه حساب های فرعی ایجاد کنیم
حساب‌های فرعی برای نقشه‌برداری برای کاربران در نظر گرفته شده است. اگر یک کاربر می تواند بیش از یک دارایی (به عنوان مثال یک زیر دامنه یا پوشه، یا صفحات نمایه) در پلتفرم شما داشته باشد، حساب فرعی که برای آن کاربر نگاشت شده است باید شامل همه ویژگی های مرتبط با آن کاربر باشد.
مقدار "request_id" در این سناریو
اگر پلتفرم شما چندین ویژگی را برای هر کاربر مجاز می‌کند، توصیه می‌کنیم از یک شناسه منحصربه‌فرد داخلی برای کاربر در قسمت request_id استفاده کنید. در آینده، متد get account API امکان دریافت حساب‌ها بر اساس مقدار این فیلد را فراهم می‌کند.