REST API

 

/*웹 API 특성*/

1. 모든 클라이언트는 내부에서 API가 구현되는 방법에 관계없이 API를 호출할 수 있어야 한다.

2. API가 진화해도 기존 클라이언트 애플리케이션은 수정 없이 계속 작동할 수 있어야 한다.

 

/*REST (Representational State Transfer)*/

- REST API는 리소스 중심으로 디자인 되며, 클라이언트에서 액세스 할 수 있는 모든 종류의 개체, 데이터, 서비스가 리소스에 포함된다.

- 리소스를 식별하는 URI 식별자가 있다.

- REST API는 상태 비저장 요청 모델 사용 (한번 요청을 했다고 해서 그 상태 정보를 저장할 수 없다)

-  URI는 명사 기반으로 작성하는 것이 좋다

 

/*API 작업 정의*/

GET : 지정된 URI에서 리소스의 표현을 검색

POST : 지정된 URI에 새 리소스를 만든다

PUT : 지정된 URI에 리소스를 만들거나 대체

PATCH : 리소스의 부분 업데이트 수행

DELETE : 지정된 URI의 리소스 제거

 

** PATCH : 전체 표현이 아닌 변경 내용만 보내기 때문에 PUT을 사용하는 것보다 이 방법이 효율적일 수 있다.

 

/*비동기 일 때*/

시간이 걸리는 처리가 필요. 

요청 처리가 수락되었지만 아직 완료되지 않았음을 나타내는 202 (수락됨)을 반환한다.

 

/*버전 관리*/

1. URI 버전 관리 : 

https://localhost:8080/v2/customers/3

 

- 간단하다. 하지만, 웹 API가 성숙해짐에 따라 서버가 다양한 버전을 지원해야 한다. 버전이 달라도 리소스 형태에 변환이 없는 URI가 있을 수 있다. 이때는 서버 낭비를 불러 일으킬 수 있다.

 

2. 쿼리 문자열 버전 관리 

https://localhost:8080/customers/3?version=2

 

- 매개변수를 사용한다. 언제나 같은 URI에서 검색이 된다. 쿼리 문자열을 분석하고 해당 HTTP 응답을 다시 보내기 위해 요청을 처리하는 코드에 따라 달라진다. 접근 방식이 복잡하다.

 

3. 헤더 버전 관리

 

헤더에 headers = {버전정보}를 설정하여 헤더값으로 버전정보를 받도록 하였다 (Spring). version 헤더가 생략된 경우 기본값 (버전1) 사용 가능.

 

4. 미디어 형식 버전 관리

 

produces = {버전정보} 를 설정하여 헤더값으로 버전정보를 받도록 하였다.

Accept 헤더를 사용

GET http://localhost:8080/customer/3 HTTP/1.1
Accept : application/app-works.v1+json

 

 

헤더 버전 관리, 미디어 형식 버전 관리에는 추가 논리가 필요하다. 대규모 환경의 경우, 서로 다른 웹 버전의 웹 API를 사용하는 클라이언트가 서버 쪽 캐시에 상당한 양의 중복된 데이터를 발생시킬 수 있다.