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

ใน 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/v1beta/accounts/{account}/users/{email}
• GET /accounts/v1beta/accounts/{account}/users
• POST /accounts/v1beta/accounts/{account}/users
• PATCH /accounts/v1beta/accounts/{account}/users/{email}
• DELETE /accounts/v1beta/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.update	อัปเดตสิทธิ์เข้าถึงของผู้ใช้
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