REST

1. REST
김영남

2. REST의 3요소
 메서드
 무엇을 할 것인가?
 리소스
 행위의 대상
 리소스 지향 아키텍처 스타일답게 모든것을 리소스(명사)로 표현함(REST형태의 디자인)
 Push 메시지를 보낸다 → /myweb/sendpush(X)
 Push 메시지 요청을 생성한다 → POST/myweb/push(O)
 메시지
 행위의 내용
메서드 의미
POST Create
GET Select
PUT Update
DELETE Delete

3. REST의 특성
 유니폼 인터페이스(Uniform Interface)
 HTTP 표준만 따르면 어떠한 기술(언어)이든지 사용가능
 무상태성(Stateless)
 Client의 context를 서버쪽에 유지하지 않음
 API서버는 들어오는 요청만 메시지로 처리하면 됨
 캐시 가능(Cacheable)
Client REST Component
GET/partners/UK
304 Not Modified(No content)

4. REST의 특성
 자체표현구조(Self-descriptiveness)
 API메시지만 보고도 이해 할 수 있는 자체 표현 구조
 클라이언트 서버 구조(Client-Server)
 클라이언트와 서버간 개발 의존성이 줄어듦
 계층형 구조(Layered System)
Client Server
사용자 인증, Context(세션, 로그인정보) 직접 관리 API제공, 비즈니스 로직 처리 및 저장
Client
Server Side
API Call
사용자 인증 암호화 로드 밸런스 …
Server Server Server Server
Server
Server

5. REST 안티 패턴
 GET/POST를 이용한 터널링
 HTTP응답 코드를 사용하지 않음
 성공은 200, 실패는 500과 같이 1~2개의 HTTP응답 코드만 사용하는 경우
터널링 잘못된 내용
HTTP GET, http://myweb/users?method=update&id=terry
실제 동작은 리소스를 업데이트 하는 내용인데
HTTP PUT을 사용하지 않고 GET에 쿼리 파라미터로
method=update를 사용함
HTTP POST, http://myweb/users/
{
“getuser”:{
“id”:”terry”,
}
}
Insert가 아닌데도 POST메소드를 통해 JSON바디에
operation명을 넘기는 형태

6. REST의 문제점
 JSON + HTTP를 쓰면 REST인가?
 리소스를 제대로 정의하고 이에 대한 CRUD를 HTTP 메서드인
POST/PUT/GET/DELETE에 맞춰 사용해야 함
 표준 규약이 없다
 표준이 없어 관리가 어렵다(메시지 구조에 대한 정의 및 규약이 없다)
 사용할 REST에 대한 자체 표준을 정해야 함
 프로젝트 별 REST API표준 가이드 및 API Spec문서를 만들어야 함
 전통적인 RDBMS에 적용하기 쉽지 않다
 Primary key가 단일key가 아닐경우 URI표현이 매우 부자연스러워짐
 대체key사용 → 전체 DB구조 변경해야함

7. REST API 보안
 인증(Authentication)
 API키 방식
 Client는 API키를 발급받고 API를 호출할때 API키를 메시지에 넣어서 호출
 모든 클라이언트가 API키를 공유하기 때문에 한번 API키가 노출되면 전체 API가 뚫림
 API토큰 방식
 ID/비밀번호 등으로 사용자 인증 후 사용제한 기간이 있는 API토큰을 발급
 API토큰을 탈취당하면 API call은 가능하지만 사용자의 ID/비밀번호는 탈취 당하지 않음
 HTTP Basic Auth, Digest Access Authentication, OAuth 2.0등
 JWT(Json Web Token)방식
 사용자에 대한 추가정보를 토큰에 저장함
 사용자의 접근 권한을 추가적으로 확인할 필요가 없음
{
“id”:”terry”
, “role”:[“admin”,”user”]
, “company”:”pepsi”
}

8. REST API 보안
 권한 인가(Authorization)
 API인가 방식
 사용자의 역할 기반(Admin, User, …)
 사용자에게 API별 직접 권한 부여
 API권한 인가 처리 위치
 네트워크(전송) 레벨 암호화
 HTTPS보안 프로토콜 : 가장 기본적이고 필수적인 REST API 보안방법
 추가적으로 공인인증서 사용에 대해 검토 해야 함
 메시지 본문 암호화
 메시지 무결성 보장
 HMAC등
위치 특징
클라이언트 클라이언트를 신뢰 할 수 있을 경우에만 사용 가능
게이트웨이 사용자 권한 인증에 필요한 데이터가 있을 수 있기 때문에 사용하기 어려움
서버 일반적이고 보편적인 방법, 비즈니스 로직에 구현