[제안] REST API 구성에 관한 몇 가지 제안.

[gongdo]

보다 바람직한 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참고

[jangbora]

말씀하신대로 400과 401에 대한 구분이 필요하고 401응답시 WWW-Authorize헤더가 포함되어야 할 것 같습니다.
또한, Authorization헤더와 관련해서는 http://tools.ietf.org/html/rfc1945#section-11 내용을 참고해 추가 설계를 할 필요가 있을 것 같습니다.

[jangbora]

말씀하신대로 400과 401에 대한 구분이 필요하고 401응답시 WWW-Authorize헤더가 포함되어야 할 것 같습니다.
또한, Authorization헤더와 관련해서는 http://tools.ietf.org/html/rfc1945#section-11 내용을 참고해 추가 설계를 할 필요가 있을 것 같습니다.

[jangbora]

WWW-Authorize헤더 정의

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_을 적용

[jangbora]

WWW-Authorize헤더 정의

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_을 적용