보다 바람직한 HTTP REST API를 위해 다음의 사안을 제안합니다.
물론 이 내용은 기존 API에 영향을 주게 되므로 적용할 수 없을 것입니다.
혹시 다음 버전의 API를 계획하신다면 그 때는 이 제안을 고려해 볼 수 있을 것입니다.
HTTP 응답 코드에 관하여
다음과 같이 응답코드를 정리할 것을 제안합니다.
400 Bad Request - 입력 파라미터가 없거나 유효하지 않은 값일 경우(data-validation) 401 Unauthorized - access token을 제시하지 않은 경우(현재는 400을 반환하고 있음) 404 Not Found - 요청한 리소스(payment, preparation 등)가 존재하지 않는 경우
Authorization (권한 인증)에 관하여
권한 인증의 과정에서 사용되는 HTTP 헤더와 결과를 다음과 같이 정리하는 것이 좀 더 HTTP 스럽다고 생각합니다.
토큰을 전송하는 헤더는 Authorization을 사용
토큰이 없거나 인증에 실패한 경우 401 Unauthorized로 응답.
401응답시 반드시 WWW-Authorize 헤더를 포함(값은 token 또는 iamport등 자유롭게 써도 무방하리라고 봄) *RFC 7235 4.1참고
The text was updated successfully, but these errors were encountered:
iamport scheme 을 사용하는 것으로 확정 ex)WWW-Authorize: iamport
Authorization 헤더 구성
기존과 유사하게, auth-scheme, auth-param와 같은 필드는 추가하지 않음. Authorization: access_token
을 활용하며, 하위 호환성을 위해 기존의 _X-ImpTokenHeader: access_token_도 인정 Authorization: access_token1 과 _X-ImpTokenHeader: access_token2_가 동시에 request되는 경우는 _Authorization: access_token1_을 적용
보다 바람직한 HTTP REST API를 위해 다음의 사안을 제안합니다.
물론 이 내용은 기존 API에 영향을 주게 되므로 적용할 수 없을 것입니다.
혹시 다음 버전의 API를 계획하신다면 그 때는 이 제안을 고려해 볼 수 있을 것입니다.
HTTP 응답 코드에 관하여
다음과 같이 응답코드를 정리할 것을 제안합니다.
400 Bad Request
- 입력 파라미터가 없거나 유효하지 않은 값일 경우(data-validation)401 Unauthorized
- access token을 제시하지 않은 경우(현재는 400을 반환하고 있음)404 Not Found
- 요청한 리소스(payment, preparation 등)가 존재하지 않는 경우Authorization (권한 인증)에 관하여
권한 인증의 과정에서 사용되는 HTTP 헤더와 결과를 다음과 같이 정리하는 것이 좀 더 HTTP 스럽다고 생각합니다.
Authorization
을 사용401 Unauthorized
로 응답.401
응답시 반드시WWW-Authorize
헤더를 포함(값은 token 또는 iamport등 자유롭게 써도 무방하리라고 봄) *RFC 7235 4.1참고The text was updated successfully, but these errors were encountered: