Przenoszenie zarządzania użytkownikami i dostępem

W Content API for Shopping użytkownikami i ich prawami dostępu zarządzało się za pomocą pola w zasobie Account. Interfejs Merchant API zastępuje to 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:

• Dedykowane zasoby: ta opcja zapewnia bardziej szczegółowy i bezpośredni sposób kontrolowania, kto ma dostęp do Twojego konta Merchant Center i co może na nim robić.
• Nazwy zasobów RESTful: w Merchant API identyfikuj zasoby User za pomocą pełnej nazwy zasobu, np. accounts/12345/users/example@example.com.
• mealias: możesz użyć aliasu me zamiast adresu e-mail w nazwie zasobu, aby odwołać się do uwierzytelnionego użytkownika, np. accounts/12345/users/me.
• Skonsolidowane prawa dostępu: Merchant API konsoliduje pola dostępu typu boolean z Content API (np. admin, reportingManager) w jedno powtarzalne pole access_rights.
• Zapraszanie i weryfikacja użytkowników: interfejs 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 przypadku Content API for Shopping. Dodaj ## Żądania

Interfejs 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 znajdziesz porównanie adresów 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 znajdziesz porównanie identyfikatorów używanych w żądaniach między interfejsem Content API for Shopping a 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 znajdziesz porównanie metod interfejsu 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.update	Aktualizuje uprawnienia dostępu użytkownika.
accounts.update	users.delete	Usuwa użytkownika z konta.

Szczegółowe zmiany w polach

Zmień sposób używania pól w ten sposób:

Content API for Shopping	Merchant API	Opis
users (powtórzono AccountUser)	users (powtórzono 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. Określ go w polu user_id podczas tworzenia.
AccountUser.admin	access_rights: "ADMIN"	Interfejs Merchant API zastępuje pole logiczne admin wartością ADMIN w wyliczeniu access_rights.
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst	access_rights: "STANDARD"	Interfejs Merchant API zastępuje te role STANDARD prawem dostępu.
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	Rola reporting_manager to teraz uprawnienie dostępu PERFORMANCE_REPORTING.
AccountUser.read_only	access_rights: "READ_ONLY"	Rola read_only to teraz uprawnienie 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.