Memigrasikan pengelolaan pengguna dan akses

Di Content API for Shopping, Anda mengelola pengguna dan hak akses mereka dengan kolom di resource Account. Merchant API mengganti ini dengan resource khusus bernama User dan metode yang sesuai (create, delete, get, list, path). Untuk mengetahui informasi selengkapnya, lihat Mengontrol akses ke akun Anda.

Perbedaan utama

Dibandingkan dengan Content API for Shopping, Merchant API menawarkan keuntungan berikut untuk pengelolaan pengguna:

• Resource khusus: Fitur ini memberikan cara yang lebih terperinci dan langsung untuk mengontrol siapa yang dapat mengakses akun Merchant Center Anda dan apa yang dapat mereka lakukan.
• Nama resource RESTful: Di Merchant API, identifikasi resource User dengan nama resource lengkap, misalnya, accounts/12345/users/[e-mail].
• Alias me: Anda dapat menggunakan alias me sebagai pengganti alamat email di nama resource untuk merujuk ke pengguna yang diautentikasi, misalnya, accounts/12345/users/me.
• Hak akses gabungan: Merchant API menggabungkan kolom akses boolean dari Content API (misalnya, admin, reportingManager) ke dalam satu kolom access_rights yang dapat diulang.
• Undangan dan verifikasi pengguna: Merchant API memperkenalkan status pengguna eksplisit (PENDING atau VERIFIED). Saat Anda membuat pengguna baru, pengguna tersebut akan berada dalam status PENDING hingga menerima undangan. Hal ini memberikan visibilitas API ke status pengguna, yang tidak tersedia di Content API for Shopping. Menambahkan ## Permintaan

Merchant API menggunakan URL permintaan berikut untuk mengelola pengguna:

• GET /accounts/v1beta/accounts/{account}/users/{email}
• GET /accounts/v1beta/accounts/{account}/users
• POST /accounts/v1beta/accounts/{account}/users
• PATCH /accounts/v1beta/accounts/{account}/users/{email}
• DELETE /accounts/v1beta/accounts/{account}/users/{email}

Tabel berikut membandingkan URL permintaan antara Content API for Shopping dan Merchant API.

Deskripsi permintaan	Content API for Shopping	Merchant API
Mendapatkan pengguna untuk akun	GET {api_version}/{merchantId}/accounts/{accountId}	GET {api_version}/accounts/{account}/users
Membuat pengguna	PATCH {api_version}/{merchantId}/accounts/{accountId}	POST {api_version}/accounts/{account}/users
Memperbarui pengguna	PATCH {api_version}/{merchantId}/accounts/{accountId}	PATCH {api_version}/accounts/{account}/users/{email}
Hapus pengguna	PATCH {api_version}/{merchantId}/accounts/{accountId}	DELETE {api_version}/accounts/{account}/users/{email}

Pengenal

Tabel berikut membandingkan ID yang digunakan dalam permintaan antara Content API for Shopping dan Merchant API.

Deskripsi ID	Content API for Shopping	Merchant API
ID akun	accountId	account di accounts/{account}
ID pengguna	email_address dalam objek AccountUser	email di accounts/{account}/users/{email}

Metode

Tabel berikut membandingkan metode antara Content API for Shopping dan Merchant API.

Content API for Shopping	Merchant API	Ketersediaan & catatan
accounts.update	users.create	Membuat pengguna baru untuk akun.
accounts.get	users.get	Mengambil satu pengguna.
accounts.get	users.list	Mencantumkan semua pengguna untuk akun.
accounts.update	users.update	Memperbarui hak akses pengguna.
accounts.update	users.delete	Menghapus pengguna dari akun.

Perubahan kolom mendetail

Perbarui penggunaan kolom Anda sebagai berikut:

Content API for Shopping	Merchant API	Deskripsi
users (berulang AccountUser)	users (berulang User)	Resource User sekarang menjadi resource tingkat teratas dengan layanannya sendiri.
AccountUser.email_address	CreateUserRequest.user_id dan bagian dari User.name	Alamat email pengguna kini menjadi bagian dari nama resource. Tentukan di kolom user_id selama pembuatan.
AccountUser.admin	access_rights: "ADMIN"	Merchant API menggantikan kolom boolean admin dengan nilai ADMIN dalam enum access_rights.
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst	access_rights: "STANDARD"	Merchant API menggantikan peran ini dengan hak akses STANDARD.
AccountUser.reporting_manager	access_rights: "PERFORMANCE_REPORTING"	Peran reporting_manager kini menjadi hak akses PERFORMANCE_REPORTING.
AccountUser.read_only	access_rights: "READ_ONLY"	Peran read_only kini menjadi hak akses READ_ONLY.
Tidak tersedia	User.name	Berisi nama resource lengkap pengguna, misalnya, accounts/{account}/users/{email}.
Tidak tersedia	User.state	Menunjukkan status undangan pengguna, baik PENDING maupun VERIFIED.