REST API
- REST API 에서 REST는 Representational State Transfer 의 약자로 소프트웨어 프로그램 아키텍처의 한 형식 입니다.
- 즉, 자원을 이름 (자원의 표현) 으로 구분하여 해당 자원의 상태 (정보)를 주고 받는 모든 것을 의미한다.
- 월드 와이드 웹 (WWW) 과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
6가지 원칙
- Uniform Interface
- 여러 URL과 Method는 일관성이 있어야한다.
- 하나의 URL로 하나의 데이터를 가져오게 디자인 해야한다.
- 간결하고 예측가능하게 URL과 Method를 만든다.
- Client-server 역할 구분
- 유저에게 서버역할을 맡기거나 DB를 직접 입출력하게 하면 안된다.
- Stateless
- 요청들은 서로 의존성이 있으면 안되고, 각각 독립적으로 처리되어야 한다.
- Cachealbe
- 서버가 보내는 자료들은 캐싱이 가능해야한다.
- Layered System
- 서버 기능을 만들 때 레이어를 걸쳐서 코드가 실행되도록 만들어도 된다.
- Code on demand
- 서버는 실행 가능한 코드를 보낼 수 있다.
세부 규칙
- 슬래시 구분자 ( / )는 계층 관계를 나타내는데 사용한다.
-
URI 마지막 문자로 슬래시 ( / )를 포함하지 않는다.
- 즉 URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것
- 역으로 리소스가 다르면 URI도 달라져야 한다.
-
하이픈 ( - )은 URI 가독성을 높이는데 사용한다.
- 밑줄 ( _ )은 URI에 사용하지 않는다.
-
URI 경로에는 소문자가 적합하다.
- URI 경로에 대문자 사용은 피하도록 한다.
-
파일확장자는 URI에 포함하지 않는다.
- REST API 에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
- 대신 Accept Header 를 사용한다.
- ex) GET: http://restapi.exam.com/orders/2/Accept: image/jpg
-
리소스 간에 연관 관계가 있는 경우
- /리소스명/리소스ID/관계가 있는 다른 리소스 명
- ex) GET: /users/2/orders (일반적으로 소유의 관계를 표현할 때 사용)
ha lee :)