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

ใน 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/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