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

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

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

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

• ทรัพยากรเฉพาะ: วิธีนี้ช่วยให้คุณควบคุมผู้ที่มีสิทธิ์เข้าถึงบัญชี Merchant Center และสิ่งที่บุคคลเหล่านั้นทำได้โดยละเอียดและตรงจุดมากขึ้น
• ชื่อทรัพยากร RESTful: ใน Merchant API ให้ระบุทรัพยากร User ด้วยชื่อทรัพยากรแบบเต็ม เช่น accounts/12345/users/example@example.com
• ชื่อแทน 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