โครงสร้างบัญชีย่อย

โครงสร้าง 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

สำคัญ: สำหรับกรณีการใช้งานนี้ เรากำหนดให้ต้องมีเมตาแท็ก"ผู้เขียนแพลตฟอร์ม" อยู่ในทุกหน้าด้วย
littlepig (หรือรหัสที่ไม่ซ้ำภายในที่เชื่อมโยงกับผู้ใช้)

วิธีสร้างบัญชีย่อยในกรณีที่ผู้ใช้มีพร็อพเพอร์ตี้หลายรายการในแพลตฟอร์ม

บัญชีย่อยมีไว้เพื่อจับคู่กับผู้ใช้ หากผู้ใช้รายเดียวเป็นเจ้าของพร็อพเพอร์ตี้ได้มากกว่า 1 รายการ (เช่น ซับโดเมนหรือโฟลเดอร์ หรือหน้าโปรไฟล์) ในแพลตฟอร์มของคุณ บัญชีย่อยที่เชื่อมโยงกับผู้ใช้รายนั้นต้องมีพร็อพเพอร์ตี้ทั้งหมดที่เชื่อมโยงกับผู้ใช้รายนั้น

ค่า "request_id" ในสถานการณ์นี้

หากแพลตฟอร์มของคุณอนุญาตให้ใช้พร็อพเพอร์ตี้หลายรายการต่อผู้ใช้ เราขอแนะนําให้ใช้ตัวระบุที่ไม่ซ้ำกันภายในสําหรับผู้ใช้ในช่อง request_id ในอนาคต เมธอด get account API จะอนุญาตให้รับบัญชีตามค่าของฟิลด์นี้