REST API
Reprensentational State Transfer API
정의
- REST하게 API를 서술하는 방법
- 상태를 전달하는 것을 나타내는 방법
- 자원을 이름(표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것
- 특정 데이터(리소스, URI)를 어떤 방식(http method)으로 전달하겠다.
URI: Uniform Resource Indentifier
장점
- Self-descriptiveness
- 그 자체만으로도 API의 목적이 쉽게 이해됨
RESTful API 예시 : [GET] http://starbucks.com/beverages/1
RESTful API vs SOAP
SOAP
Simple Object Access Protocol
: XML 기반의 메시지 전송 프로토콜
- 원격 프로시저 호출 패턴
- 플랫폼에 종속되지 않아 다른 기종 간 통신 가능
- Header와 Body를 가지며 헤더에는 메타 정보, 바디에는 실제 정보가 들어가 있음
- 규약, 에러 처리, 분산 처리에 대한 옵션이 내장되어 있음
- 보편적인 웹 서비스보다는 기업 또는 특정 조직 내부에서 사용하는게 적합
차이점
- REST와 SOAP은 가장 보편화되어 사용되고 있는 웹 API 패러다임이다.
- SOAP은 프로토콜이고, REST는 api 설계 스타일로 본질적으로 다른 기술이다.
- REST는 리소스(데이터) 중심으로 묘사되고, SOAP은 행위, 기능 중심으로 서술된다.
- 보안이나 메세지 전송 방식 등이 다르다.
- 보편적인 웹 서비스에서는 HTTP를 통한 REST를 사용한다.
a. REST는 여러가지 형태의 데이터 (html, json, text)를 전송하고, SOAP은 XML 데이터만을 고정적으로 전송한다.
b. REST는 요청과 응답에 대한 캐시를 사용할 수 있어 보다 효율적이다.
c. REST는 ACID 특성과 관련된 내용이 없지만 SOAP는 자체 기준이 있다.
RESTful API 설계 원칙
1. Uniform Interface
- REST는 API를 설계할 때 자원을 중심으로 만드는 것이 원칙
- URI 자원으로 한정된 일관적인 인터페이스 (uniform interface)를 구현하는 것으로 자원 조작을 통일하는 것이 좋다.
- 일반적으로 HTTP를 구성하는 URL, HTTP method, Status Code를 통해 인터페이스를 구현한다.
- 어떠한 요청을 진행할 대상(URI)은 자원이므로, 해당 자원을 정확하게 지칭하는 명사(동사 X)로 구성하는 것이 좋다.
- Resource에 대한 행위를 HTTP method (GET, POST, PUT, DELETE)만으로 표현한다.
- Resource 사이에 연관 or 계층 관계가 있는 경우 slash('/') 를 사용한다.
ex) /resource/고유 ID/연관 관계 있는 resource
[GET] /users/{user_id}/profile - URI 마지막 문자로 / 를 포함하지 않는다.
- URI가 길어지는 경우 - 를 사용한다.
- 파일 확장자(ex. .jpg)는 URI에 포함시키지 않는다. payload에 포함되는 파일의 확장자는 headers에 포함한다.
- 응답 Response 의 status code의 기본적인 규칙을 따른다.
2. Client - Server
- 데이터를 저장하는 데이터 스토리지 부분과, 이를 활용하고 서비스를 구동하는 유저 인터페이스의 분리
- 서버는 API를 제공하는 역할만 수행하고, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보등)를 직접 관리한다.
3. Stateless
- API서버는 들어오는 요청만을 단순히 처리하고 결과(상태)에 대한 정보를 따로 저장하거나 관리 하지 않음
- 장점: 서비스의 자유도가 높아지고, 서버에서 불필요한 정보를 관리하지 않음으로서 서비스 구현이 단순해진다.
코드의 가시성과 안정성이 확보되고, 더 간편하게 확장될 수 있다. - 단점: 서버가 세션 정보, 쿠키 정보 또한 별도로 저장하거나 관리하지 않기 때문에 클라이언트에서 상태 정보를 항상 전송해야한다. 따라서 통신 비용이 높아진다.
4. Cacheable
- HTTP가 기본적으로 가지고 있는 캐시 정책을 사용할 수 있다.
- 통신 비용이 높아짐을 해결하기 위한 정책
- 요청에 관한 응답을 따로 저장함으로써 추후에 재사용이 가능
- 클라이언트-서버의 상호작용을 제거하여 성능을 향상시키고 확장성을 보장할 수 있다.
- 단점: 응답을 매번 갱신하는 것이 아니기 때문에 서버측에서 업데이트된 데이터가 반영되지 않고 신뢰성을 감소시킬 우려가 있음
5. Layered System
- 복잡한 여러 기능을 계층화 시켜서 한 기능씩 순차적으로 진행하도록 설계 되어 있다.
- 특정 기능이 진행되는 동안 다른 레이어의 시스템은 확인할 수 없어 시스템의 복잡도가 낮다.
- 레이어 중간에 공유 중개자를 두어 로드밸런싱 및 캐시 정책을 도입할 수 있다.
- 계층별로 독립적인 기능을 수행하기 때문에, 특정 기능이 오래되어 (레거시 서비스) 교체가 필요할 때에도 새로운 서비스를 완전히 격리할 수 있다.
- 단점: 계층적으로 일이 처리되다 보면 데이터 처리에 과부하가 걸려 응답이 늦어질 수 있다.
6. Code on Demand (optional)
- 서버로부터 내려받은 기능(프로그램)들은 클라이언트에서 바로 실행할 수 있어야 한다
- 정적인 데이터를 xml 또는 json에 담아 client에서 가공하는 방식이 아닌 바로 실행 가능한 코드 형태의 데이터를 보내어 client가 곧바로 실행하는 것
- 단점: 시스템 확장성이 향상되지만, 클라이언트 입장에서는 실행할 코드를 백엔드에서 받기 전에는 전혀 알 수가 없다.
- 조직 내부에서는 사용 가능하지만, 외부에서는 사용이 불가능할 수 있다.
냐하