[요약] REST API 디자인 규칙 - 06. 클라이언트 영역

버져닝

새 개념은 새 URI로

• 의미론 적으로 새로운 기능을 제공하는 경우 새 URI 를 사용한다.
• 의미론 적으로 같다면 URI 가 바뀌어서는 안된다: URI 는 버져닝을 하지 않는다.

요약자 주.
본 서적에서는 URI 로는 버져닝을 하지 말것을 제시하고 있다. 개념적으로 같은 기능에 버져닝이 들어간다는것은 "유일한 식별자" 로서의 제약사항을 위배하기 때문이라 생각된다. 그러나 현재의 RESTful API 는 필수적으로 버져닝을 다루고 있다.

• URI에 추가
• query parameter 로 받기
• custom header
• 컨텐츠 협상

추정컨데, 본 서적은 WRML 기반의 REST API 구현론을 제시하는 책이므로 URI 에서 버져닝을 하는 대신 WRML 스키마를 통해 버져닝을 대신할 수 있다고 판단하기 때문에 그렇게 기술한게 아닌가 싶다. 현재의 최신 웹 트랜드에서는 버져닝을 중요한 주제로 다루고 있으므로 위 제약 사항은 적절하지 않다고 생각한다.

ETag

ETag 는 문서의 고윳값이므로 그 자체만으로 버져닝을 한다고 볼 수 있다.

 

보안

OAuth

• 권한 부여를 위해 OAuth 를 사용할 수 있다.
• OAuth 를 이용하려는 Client (Application server) 와 Resource Server 를 분리한다.
• Client 는 Authorization Server 로 부터 발급받은 Access Token 으로 Resource Server 에 접근한다.
• Resource Server 는 Client 가 제시한 Access Token 을 검증하여 허가 받은 행위를 허용한다.

요약자 주.
OAuth 는 개인정보의 소유자와 사용자를 분리하는 표준으로, 특정 서비스를 사용하기 위해 사용자가 개인정보를 제출해야만 하는 상황을 막아준다. 일반적인 OAuth 2.0 의 플로우는 다음과 같다.

1. 사용자가 클라이언트에 로그인을 요청한다.
2. 클라이언트는 사용자를 인증 서버의 로그인 페이지로 리다이렉션 한다. 이때 클라이언트의 콜백 정보를 넘겨준다.
3. 사용자는 인증 서버에 로그인을 한다.
4. 인증 서버는 사용자를 클라이언트의 콜백 주소로 리다이렉션 한다. 이때 Authorization Code 를 함께 전달한다.
5. 클라이언트는 Authorization Code 를 인증 서버에 제출한다.
6. 인증 서버는 클라이언트에 Access Token 을 발급해준다.
7. 인증 서버는 Access Token 으로 Resource Server 에 접근한다.
8. Resource Server 는 클라이언트가 제시한 Access Token 이 유효하고 요청한 작업에 권한이 있다면 이를 수용한다.

OAuth 2.0 에서는 8번, Access Token 의 유효성 검증에 대한 별도의 표준은 없으며 크게 두가지 방법을 이용한다.

• 인증서버에서 제공하는 API 로 Access Token 을 검증.
• Access Token 가 전자 서명 키이며, 이를 공개키로 검증.

CORS

• Cross-Orrigin Resource Sharing 을 지원한다.
• 서버는 Access-Control-Allow-Origin 헤더에 CORS 를 허용하는 사이트를 기록하여 클라이언트에 제공한다.
• 서버는 Access-Control-Request-Method 헤더에 CORS 를 허용하는 method 를 기록하여 클라이언트에 제공한다.
• 클라이언트는 JavaScript 를 이용해 런타임에 Cross Site 요청을 보낼 수 있다.