Перенос управления пользователями и доступом

В 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 в перечислении 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.