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.