โครงสร้างบัญชีย่อย
โครงสร้าง URL ของแพลตฟอร์มของคุณเป็นตัวขับเคลื่อนหลักในการจัดโครงสร้างของบัญชีย่อย โดยเฉพาะอย่างยิ่ง ช่อง site_uri ควรมีลักษณะอย่างไร
ดูโครงสร้างเว็บไซต์ที่ AFP รองรับประเภทต่างๆ ด้านล่าง
| Use Case | โครงสร้าง 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 (หรือรหัสที่ไม่ซ้ำกันภายในที่เชื่อมโยงกับผู้ใช้) |
วิธีสร้างบัญชีย่อยหากผู้ใช้มีพร็อพเพอร์ตี้หลายรายการในแพลตฟอร์มของคุณ
บัญชีย่อยมีไว้เพื่อแมปกับผู้ใช้ หากผู้ใช้รายหนึ่งเป็นเจ้าของพร็อพเพอร์ตี้ได้มากกว่า 1 รายการ (เช่น โดเมนย่อยหรือโฟลเดอร์ หรือหน้าโปรไฟล์) ในแพลตฟอร์มของคุณ บัญชีย่อยที่แมปกับผู้ใช้รายนั้นต้องมีพร็อพเพอร์ตี้ทั้งหมดที่เชื่อมโยงกับผู้ใช้รายนั้น
ค่าของ "request_id" ในสถานการณ์นี้
หากแพลตฟอร์มของคุณอนุญาตให้มีพร็อพเพอร์ตี้หลายรายการต่อผู้ใช้ เราขอแนะนำให้ใช้ตัวระบุที่ไม่ซ้ำกันภายในสำหรับผู้ใช้ในช่อง request_id ในอนาคต เมธอดรับ API ของบัญชีจะอนุญาตให้รับบัญชีตามค่าของช่องนี้ได้