쇼핑용 Content API에서는 Account
리소스의 필드를 사용하여 사용자와 액세스 권한을 관리했습니다. Merchant API는 이를 User
라는 전용 리소스와 해당 메서드 (create, delete, get, list, path)로 대체합니다. 자세한 내용은 계정 액세스 제어를 참고하세요.
주요 차이점
Content API for Shopping과 비교할 때 Merchant API는 사용자 관리에 다음과 같은 이점을 제공합니다.
- 전용 리소스: 판매자 센터 계정에 액세스할 수 있는 사용자와 해당 사용자가 할 수 있는 작업을 더 세부적이고 직접적인 방식으로 관리할 수 있습니다.
- RESTful 리소스 이름: Merchant API에서 전체 리소스 이름(예:
accounts/12345/users/example@example.com
)으로User
리소스를 식별합니다. 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/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}
다음 표에서는 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 ). |