Di chuyển hoạt động quản lý người dùng và quyền truy cập

Trong Content API for Shopping, bạn quản lý người dùng và quyền truy cập của họ bằng một trường trong tài nguyên Account. Merchant API thay thế tài nguyên này bằng tài nguyên chuyên dụng có tên là User và các phương thức tương ứng (create, delete, get, list, path). Để biết thêm thông tin, hãy xem bài viết Kiểm soát quyền truy cập vào tài khoản của bạn.

Những điểm khác biệt chính

So với Content API for Shopping, Merchant API mang lại những lợi ích sau đây cho việc quản lý người dùng:

  • Tài nguyên chuyên dụng: Cách này giúp bạn kiểm soát chi tiết và trực tiếp hơn đối với những người có thể truy cập vào tài khoản Merchant Center của bạn và những việc họ có thể làm.
  • Tên tài nguyên RESTful: Trong Merchant API, hãy xác định tài nguyên User bằng tên tài nguyên đầy đủ, ví dụ: accounts/12345/users/example@example.com.
  • me alias: Bạn có thể dùng bí danh me thay cho địa chỉ email trong tên tài nguyên để tham chiếu đến người dùng đã xác thực, ví dụ: accounts/12345/users/me.
  • Quyền truy cập hợp nhất: Merchant API hợp nhất các trường truy cập boolean từ Content API (ví dụ: admin, reportingManager) thành một trường access_rights duy nhất, có thể lặp lại.
  • Mời và xác minh người dùng: Merchant API giới thiệu trạng thái người dùng rõ ràng (PENDING hoặc VERIFIED). Khi bạn tạo một người dùng mới, họ sẽ ở trạng thái PENDING cho đến khi chấp nhận lời mời. Điều này giúp API hiển thị trạng thái của người dùng, điều mà Content API for Shopping không có. Thêm ## Yêu cầu

Merchant API sử dụng các URL yêu cầu sau để quản lý người dùng:

  • 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}

Bảng sau đây so sánh các URL yêu cầu giữa Content API for Shopping và Merchant API.

Nội dung mô tả yêu cầu Content API for Shopping Merchant API
Lấy người dùng cho một tài khoản GET {api_version}/{merchantId}/accounts/{accountId} GET {api_version}/accounts/{account}/users
Tạo người dùng PATCH {api_version}/{merchantId}/accounts/{accountId} POST {api_version}/accounts/{account}/users
Cập nhật người dùng PATCH {api_version}/{merchantId}/accounts/{accountId} PATCH {api_version}/accounts/{account}/users/{email}
Xóa người dùng PATCH {api_version}/{merchantId}/accounts/{accountId} DELETE {api_version}/accounts/{account}/users/{email}

Giá trị nhận dạng

Bảng sau đây so sánh các giá trị nhận dạng được dùng trong yêu cầu giữa Content API for Shopping và Merchant API.

Thông tin mô tả về giá trị nhận dạng Content API for Shopping Merchant API
Giá trị nhận dạng tài khoản accountId account tại accounts/{account}
Giá trị nhận dạng người dùng email_address trong đối tượng AccountUser email tại accounts/{account}/users/{email}

Phương thức

Bảng sau đây so sánh các phương thức giữa Content API for Shopping và Merchant API.

Content API for Shopping Merchant API Phạm vi cung cấp và lưu ý
accounts.update users.create Tạo một người dùng mới cho tài khoản.
accounts.get users.get Truy xuất một người dùng duy nhất.
accounts.get users.list Liệt kê tất cả người dùng của một tài khoản.
accounts.update users.update Cập nhật quyền truy cập của người dùng.
accounts.update users.delete Xoá một người dùng khỏi tài khoản.

Thông tin chi tiết về các thay đổi đối với trường

Cập nhật cách sử dụng các trường như sau:

Content API for Shopping Merchant API Mô tả
users (lặp lại AccountUser) users (lặp lại User) Tài nguyên User hiện là một tài nguyên cấp cao nhất có dịch vụ riêng.
AccountUser.email_address CreateUserRequest.user_id và một phần của User.name Địa chỉ email của người dùng hiện là một phần của tên tài nguyên. Hãy chỉ định giá trị này trong trường user_id trong quá trình tạo.
AccountUser.admin access_rights: "ADMIN" Merchant API thay thế trường boolean admin bằng giá trị ADMIN trong enum access_rights.
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst access_rights: "STANDARD" Merchant API thay thế các vai trò này bằng quyền truy cập STANDARD.
AccountUser.reporting_manager access_rights: "PERFORMANCE_REPORTING" Vai trò reporting_manager hiện là quyền truy cập PERFORMANCE_REPORTING.
AccountUser.read_only access_rights: "READ_ONLY" Vai trò read_only hiện là quyền truy cập READ_ONLY.
Không có User.name Chứa tên tài nguyên đầy đủ của người dùng, ví dụ: accounts/{account}/users/{email}.
Không có User.state Cho biết trạng thái của lời mời gửi cho người dùng, có thể là PENDING hoặc VERIFIED.