RESTful API

REST 원리를 잘 따르는 API을 RESTful API라고 한다.

RESTful의 목적

이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것 따라서 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

REST API

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용해 만든 API

REST API 특징

1. Server-Client(서버-클라이언트 구조)
2. Stateless(무상태성)
   • HTTP 프로토콜은 Stateless Protocol이므로 REST API 역시 무상태성을 갖는다.
3. Cacheable(캐시 처리 가능)
   • 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
4. Layered System(계층화)
   • Client는 REST API Server만 호출한다.
   • REST Server는 다중 계층으로 구성될 수 있다.
   • PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
5. Code-On-Demand(optional)
   • Server로부터 스크립트를 받아서 Client에서 실행한다.
6. Uniform Interface(인터페이스 일관성)
   • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.

REST API 설계 기본 규칙

1. URI는 정보의 자원을 표현해야 한다.
   • resource는 동사보다 명사를 사용
   • resource는 대문자보다 소문자를 사용
   • resource의 도큐먼트 이름으로 단수 명사를 사용
   • resource의 컬렉션 이름으로 복수 명사를 사용
   • resource의 스토어 이름으로 복수 명사를 사용
2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
   • URI에 HTTP Method가 들어가면 안됨
   • URI에 행위에 대한 동사 표현이 들어가면 안됨
   • 경로 부분 중 변하는 부분은 유일한 값으로 대체
3. 슬래시 구분자/는 계층 관계를 나타내는데 사용한다.
4. URI 마지막 문자로 슬래시/를 포함하지 않는다.
5. 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.
6. 밑줄_은 URI에 사용하지 않는다.
7. 파일확장자는 URI에 포함하지 않는다.

응답상태코드
1xx : 전송 프로토콜 수준의 정보 교환
2xx : 클라어인트 요청이 성공적으로 수행됨
3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
4xx : 클라이언트의 잘못된 요청
5xx : 서버쪽 오류로 인한 상태코드