ย้ายข้อมูลการจัดการผู้ใช้และการเข้าถึง

ใน Content API for Shopping คุณจัดการผู้ใช้และสิทธิ์เข้าถึงของผู้ใช้ด้วยฟิลด์ในทรัพยากร Account Merchant API จะแทนที่ฟิลด์นี้ด้วยทรัพยากรเฉพาะที่ชื่อว่า User และ เมธอดที่เกี่ยวข้อง (create, delete, get, list, path) ดูข้อมูลเพิ่มเติมได้ที่ ดู ควบคุมการเข้าถึงบัญชี

ความแตกต่างที่สำคัญ

เมื่อเทียบกับ Content API for Shopping แล้ว Merchant API มีข้อดีดังต่อไปนี้สำหรับการจัดการผู้ใช้

• ทรัพยากรเฉพาะ: ช่วยให้คุณควบคุมได้อย่างละเอียดยิ่งขึ้นและโดยตรงมากขึ้นว่าใครสามารถเข้าถึงบัญชี Merchant Center และทำอะไรได้บ้าง
• ชื่อทรัพยากรแบบ RESTful: ใน Merchant API ให้ระบุทรัพยากร User ด้วย ชื่อทรัพยากรแบบเต็ม เช่น accounts/12345/users/[e-mail]
• me นามแฝง: คุณสามารถใช้นามแฝง me แทนที่อยู่อีเมลใน ชื่อทรัพยากรเพื่ออ้างถึงผู้ใช้ที่ได้รับการตรวจสอบสิทธิ์แล้ว เช่น accounts/12345/users/me
• สิทธิ์เข้าถึงที่รวมไว้: Merchant API จะรวมฟิลด์การเข้าถึงแบบบูลีน จาก Content API (เช่น admin, reportingManager) ไว้ใน ฟิลด์ access_rights เดียวที่ทำซ้ำได้
• การเชิญและการยืนยันผู้ใช้: Merchant API ขอแนะนำ สถานะผู้ใช้ที่ชัดเจน (PENDING หรือ VERIFIED) เมื่อคุณสร้างผู้ใช้ใหม่ ผู้ใช้จะอยู่ในสถานะ PENDING จนกว่าจะยอมรับคำเชิญ ซึ่งจะช่วยให้ API มองเห็นสถานะของผู้ใช้ ซึ่ง Content API for Shopping ไม่มี เพิ่ม ## คำขอ

Merchant API ใช้ URL คำขอต่อไปนี้เพื่อจัดการผู้ใช้

• GET /accounts/v1/accounts/{account}/users/{email}
• GET /accounts/v1/accounts/{account}/users
• POST /accounts/v1/accounts/{account}/users
• PATCH /accounts/v1/accounts/{account}/users/{email}
• DELETE /accounts/v1/accounts/{account}/users/{email}

ตารางต่อไปนี้เปรียบเทียบ URL คำขอระหว่าง Content API for Shopping กับ Merchant API

รายละเอียดสำหรับคำขอ	Content API for Shopping	Merchant API
รับผู้ใช้สำหรับบัญชี	GET {api_version}/{merchantId}/accounts/{accountId}	GET {api_version}/accounts/{account}/users
สร้างผู้ใช้	PATCH {api_version}/{merchantId}/accounts/{accountId}	POST {api_version}/accounts/{account}/users
อัปเดตผู้ใช้	PATCH {api_version}/{merchantId}/accounts/{accountId}	PATCH {api_version}/accounts/{account}/users/{email}
ลบผู้ใช้	PATCH {api_version}/{merchantId}/accounts/{accountId}	DELETE {api_version}/accounts/{account}/users/{email}

รหัสระบุ

ตารางต่อไปนี้เปรียบเทียบรหัสระบุที่ใช้ในคำขอระหว่าง Content API for Shopping กับ Merchant API

คำอธิบายรหัสระบุ	Content API for Shopping	Merchant API
รหัสระบุบัญชี	accountId	account ใน accounts/{account}
รหัสระบุผู้ใช้	email_address ภายในออบเจ็กต์ AccountUser	email ใน accounts/{account}/users/{email}

เมธอด

ตารางต่อไปนี้เปรียบเทียบเมธอดระหว่าง Content API for Shopping กับ Merchant API

Content API for Shopping	Merchant API	ความพร้อมใช้งานและหมายเหตุ
accounts.update	users.create	สร้างผู้ใช้ใหม่สำหรับบัญชี
accounts.get	users.get	ดึงข้อมูลผู้ใช้รายเดียว
accounts.get	users.list	แสดงรายชื่อผู้ใช้ทั้งหมดสำหรับบัญชี
accounts.update	users.patch	อัปเดตสิทธิ์เข้าถึงของผู้ใช้
accounts.update	users.delete	ลบผู้ใช้ออกจากบัญชี

การเปลี่ยนแปลงฟิลด์โดยละเอียด

อัปเดตการใช้ฟิลด์ดังนี้

Content API for Shopping	Merchant API	คำอธิบาย
users (ทำซ้ำ AccountUser)	users (ทำซ้ำ User)	ตอนนี้ทรัพยากร User เป็นทรัพยากรระดับบนสุดที่มีบริการของตัวเอง
AccountUser.email_address	CreateUserRequest.user_id และส่วนหนึ่งของ User.name	ตอนนี้อีเมลของผู้ใช้เป็นส่วนหนึ่งของชื่อทรัพยากรแล้ว โปรดระบุในฟิลด์ user_id ระหว่างการสร้าง
AccountUser.admin	access_rights: "ADMIN"	Merchant API จะแทนที่ฟิลด์ admin แบบบูลีนด้วยค่า ADMIN ใน enum access_rights
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst	access_rights: "STANDARD"	Merchant API จะแทนที่บทบาทเหล่านี้ด้วยสิทธิ์เข้าถึง STANDARD
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	ตอนนี้บทบาท reporting_manager คือสิทธิ์เข้าถึง PERFORMANCE_REPORTING
AccountUser.read_only	access_rights: "READ_ONLY"	ตอนนี้บทบาท read_only คือสิทธิ์เข้าถึง READ_ONLY
ไม่พร้อมใช้งาน	User.name	มีชื่อทรัพยากรแบบเต็มของผู้ใช้ เช่น accounts/{account}/users/{email}
ไม่พร้อมใช้งาน	User.state	ระบุสถานะคำเชิญของผู้ใช้ ซึ่งอาจเป็น PENDING หรือ VERIFIED