API 란?
API는 프로그램들이 서로 상호작용을 하는 것을 도와주는 매개체라고 생각하면 된다.
하나의 프로그램이 다른 프로그램의 리소스에 연결될 수 있도록 해준다.
API는 공개 범위에 따라 3가지 유형으로 나눌 수 있다.
- Public : 개방형 API로, 모두에게 공개, 누구나 제한 없이 API를 사용 가능
- Partner :기업이 데이터 공유에 동의하는 특정인들만 사용 가능
- Private : 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행
REST 란?
자원(Resource)을 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미
구성요소
자원 (Resource)
해당 서버 API가 관리하는 모든 것을 의미하며 문서, 그림, 데이터, 해당 소프트웨어 자체 등을 의미한다.
모든 자원에는 고유한 ID인 HTTP URI 부여되며, 클라이언트는 URI를 이용하여 자원을 선택하고 해당 자원의 상태에 대한 조작을 서버에 요청한다.
Ex) /sports/soccer/players/13행위 : HTTP Method
HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 행할 행동을 정의한다.
이때 각 행동에 맞게 Method를 사용하는 것이 RESTful 한 API라고 할 수 있다.
- POST : 생성 (Create)
- GET : 조회 (Read)
- PUT : 수정 (Update)
- DELETE : 삭제 (Delete)
응답 (Representation)
클라이언트의 요청에 따라 서버는 이에 적절한 응답(Representation)을 보낸다.
REST에서 자원은 주로 JSON, XML을 통해 응답된다.
특징
서버-클라이언트 구조 : 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다.
- 서버 : API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
- 클라이언트 : 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
무상태 (Stateless) : HTTP 프로토콜은 Stateless 프로토콜이므로 REST 역시 무상태성을 갖는다.
- 작업을 위한 상태 정보를 따로 저장하고 관리하지 않으며, 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
- 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리
캐시 처리 (Cacheable) : 웹 표준 HTTP 프로토콜을 그대로 사용하므로 캐싱 기능을 적용할 수 있다.
- 캐시의 사용으로 전체 응답 시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.
- HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
계층화 (Layered System) : REST 서버는 다중 계층으로 구성될 수 있다.
- API 서버는 순수 비즈니스 로직을 수행하고, 그 외 다양한 기술들을 추가하여 구조상의 유연성을 줄 수 있다. (암호화, 사용자 인증, 로드밸런싱, 공유 캐시, 프록시, 게이트웨이 등...)
인터페이스 일관성 (Uniform Interface) : URI로 지정한 리소스에 대한 조작을 통일되고 한정적이게 지정
자체 표현 구조 (Self-descriptiveness) : REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 구성
REST API 란?
REST 기반으로 서비스 API를 구현한 것을 말한다.
시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용이 편리해지는 이점이 있다.
REST API는 자원(Resource) 기반의 구조 설계 중심에 자원이 있고
HTTP Method를 통해 이 자원을 처리하도록 설계된 하나의 애플리케이션이다.
REST API 설계 기본 규칙
URI는 정보의 자원을 표현해야 한다.
- / 는 계층 관계를 나타내는 데 사용
- URI 마지막 문자로 / 를 사용하지 않는다.
- -는 URI 가독성을 높이기 위해 사용
- _는 URI에 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함하지 않고 Accept header를 사용한다.
- 리소스는 동사보다 명사를 사용
- 리소스의 도큐멘트 이름으로는 단수 명사, 컬렉션과 스토어 이름으로는 복수 명사 사용
- 도큐멘트 : 문서 또는 하나의 객체 (데이터베이스 레코드와 유사한 개념)
- 컬렉션 : 문서들의 집합, 객체들의 집합
- 스토어 : 클라이언트에서 관리하는 리소스 저장소
자원에 대한 행위는 HTTP Method로 표현한다.
- URI에 HTTP Method가 들어가면 안 된다.
- URI에 행위에 대한 동사 표현이 들어가면 안 된다.
- 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.
- 즉 :id는 하나의 특정 resource를 나타내는 고유값이다.
Ex)
// id=12인 student를 삭제하는 경로
DELETE : /students/12
// 축구 선수 13번의 정보를 요청하는 경로
GET : /sports/soccer/players/13
// 사진의 확장자를 Accept header에 담는다
GET : /members/soccer/345/photo
(HTTP/1.1 Host: restapi.example.com Accept: image/jpg)URI는 자원을 표현하는 데에 집중하고
행위에 대한 정의는 HTTP Method를 통해 하는 것이
REST 한 API를 설계하는 중심 규칙
