Przenoszenie zarządzania użytkownikami i dostępem

W Content API for Shopping zarządzanie użytkownikami i ich uprawnieniami dostępu odbywało się za pomocą pola w zasobie Account. Merchant API zastępuje to pole dedykowanym zasobem o nazwie User i odpowiednimi metodami (create, delete, get, list, path). Więcej informacji znajdziesz w artykule Kontrolowanie dostępu do konta.

Najważniejsze różnice

W porównaniu z Content API for Shopping interfejs Merchant API oferuje te zalety w zakresie zarządzania użytkownikami:

• Dedykowany zasób: zapewnia bardziej szczegółowy i bezpośredni sposób kontrolowania, kto może uzyskać dostęp do Twojego konta Merchant Center i co może na nim robić.
• Nazwy zasobów w stylu REST: w Merchant API zasoby User są identyfikowane za pomocą pełnej nazwy zasobu, np. accounts/12345/users/[e-mail].
• me alias: zamiast adresu e-mail w nazwie zasobu możesz użyć aliasu me, aby odwołać się do uwierzytelnionego użytkownika, np. accounts/12345/users/me.
• Scentralizowane uprawnienia dostępu: Merchant API łączy pola dostępu typu boolean z Content API (np. admin, reportingManager) w jedno powtarzalne pole access_rights.
• Zapraszanie i weryfikacja użytkowników: Merchant API wprowadza wyraźny stan użytkownika (PENDING lub VERIFIED). Gdy utworzysz nowego użytkownika, będzie on w stanie PENDING, dopóki nie zaakceptuje zaproszenia. Dzięki temu interfejs API ma wgląd w stan użytkownika, co nie było możliwe w Content API for Shopping. Dodaj ## żądania

Merchant API używa tych adresów URL żądań do zarządzania użytkownikami:

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

W tabeli poniżej porównujemy adresy URL żądań w Content API for Shopping i Merchant API.

Opis prośby	Content API for Shopping	Merchant API
Pobieranie użytkowników konta	GET {api_version}/{merchantId}/accounts/{accountId}	GET {api_version}/accounts/{account}/users
Tworzenie konta użytkownika	PATCH {api_version}/{merchantId}/accounts/{accountId}	POST {api_version}/accounts/{account}/users
Aktualizowanie użytkownika	PATCH {api_version}/{merchantId}/accounts/{accountId}	PATCH {api_version}/accounts/{account}/users/{email}
Usuwanie użytkownika	PATCH {api_version}/{merchantId}/accounts/{accountId}	DELETE {api_version}/accounts/{account}/users/{email}

Identyfikatory

W tabeli poniżej porównujemy identyfikatory używane w żądaniach w Content API for Shopping i Merchant API.

Opis identyfikatora	Content API for Shopping	Merchant API
Identyfikator konta	accountId	account w accounts/{account}
Identyfikator użytkownika	email_address w obiekcie AccountUser	email w accounts/{account}/users/{email}

Metody

W tabeli poniżej porównujemy metody w Content API for Shopping i Merchant API.

Content API for Shopping	Merchant API	Dostępność i uwagi
accounts.update	users.create	Tworzy nowego użytkownika konta.
accounts.get	users.get	Pobiera pojedynczego użytkownika.
accounts.get	users.list	Wyświetla listę wszystkich użytkowników konta.
accounts.update	users.patch	Aktualizuje uprawnienia dostępu użytkownika.
accounts.update	users.delete	Usuwa użytkownika z konta.

Szczegółowe zmiany pól

Zaktualizuj sposób korzystania z pól w ten sposób:

Content API for Shopping	Merchant API	Opis
users (powtarzane AccountUser)	users (powtarzane User)	Zasób User jest teraz zasobem najwyższego poziomu z własną usługą.
AccountUser.email_address	CreateUserRequest.user_id i część User.name	Adres e-mail użytkownika jest teraz częścią nazwy zasobu. Podaj go w polu user_id podczas tworzenia.
AccountUser.admin	access_rights: "ADMIN"	Merchant API zastępuje pole typu boolean admin wartością ADMIN w wyliczeniu access_rights.
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst	access_rights: "STANDARD"	Merchant API zastępuje te role uprawnieniem dostępu STANDARD.
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	Rola reporting_manager jest teraz uprawnieniem dostępu PERFORMANCE_REPORTING.
AccountUser.read_only	access_rights: "READ_ONLY"	Rola read_only jest teraz uprawnieniem dostępu READ_ONLY.
Niedostępne	User.name	Zawiera pełną nazwę zasobu użytkownika, np. accounts/{account}/users/{email}.
Niedostępne	User.state	Wskazuje stan zaproszenia użytkownika: PENDING lub VERIFIED.