Content API for Shopping에서는 Account 리소스의 필드를 사용하여 사용자와 액세스 권한을 관리했습니다. Merchant API는 이를 전용
리소스 이름
User 및
상응하는 메서드 (create, delete, get, list, path)로 대체합니다. 자세한 내용은
계정 액세스 제어
를 참고하세요.
주요 차이점
Content API for Shopping과 비교했을 때 Merchant API는 사용자 관리에 다음과 같은 이점을 제공합니다.
- 전용 리소스: 판매자 센터 계정에 액세스할 수 있는 사용자와 수행할 수 있는 작업을 더 세부적으로 직접 제어할 수 있는 방법을 제공합니다.
- 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상태가 됩니다. 이를 통해 Content API for Shopping에서는 사용할 수 없었던 사용자 상태에 대한 API 가시성을 제공합니다. ## 요청 추가
Merchant API는 다음 요청 URL을 사용하여 사용자를 관리합니다.
GET /accounts/v1/accounts/{account}/users/{email}GET /accounts/v1/accounts/{account}/usersPOST /accounts/v1/accounts/{account}/usersPATCH /accounts/v1/accounts/{account}/users/{email}DELETE /accounts/v1/accounts/{account}/users/{email}
다음 표는 Content API for Shopping과 Merchant API 간의 요청 URL을 비교합니다.
| 요청 설명 | 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 |
accounts/{account}의 account |
| 사용자 식별자 | AccountUser 객체 내의 email_address |
accounts/{account}/users/{email}의 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.update |
사용자의 액세스 권한을 업데이트합니다. |
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 필드를 access_rights enum의 ADMIN 값으로 대체합니다. |
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)를 나타냅니다. |