โครงสร้างบัญชีย่อย
โครงสร้าง 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 จะอนุญาตให้รับบัญชีตามค่าของฟิลด์นี้