인터넷에 나와있는 설명이며, 쉽게생각해 http의 슈퍼셋이 REST라고 생각하면되는데 이 REST또한 http처럼하나의 규약이자 약속이다.
1. REST API의 탄생
REST 는 Representational State Transfer의 약자
http를 만든 사람이 웹 그러니까 http 설계의 우수성에 비해 제대로 사용되지 못함을 인지하고, 웹의 장점을 최대한 활용하다록 만든 아키텍쳐가 REST이다.
2. REST API의 구성
- resource(자원) -uri
- verb(행위) - http method
- representation(표현)
3. REST의 특징
- uniform(유니폼 인터페이스) uri로 지정한 리소스에 대해서만 조작 통일되고 한정적인 인터페이스로 수행
- stateless rest는작업을 위한 상태정보 그러니까 세션, 쿠키 정보를 따로 저장하지 않는다. 그래서 api 서버는 단순한 요청만을 처리하면 된다.
- cacheable http 웹표준을 rest는 그대로 사용하기 때문에, 웹의 기존 인프라 활용이 가능함 그중에 하나가 캐싱기능. http 프로토콜 표준에서 사용하는 lastmodified태그나 e-tag를 이용해서 캐싱 구현 가능
- self-descriptiveness rest api 메시지만 보고도 이를 쉽게 이해할 수 있음(자체표현구조)
- client - server 구조 rest 서버는 api 제공, 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분된다. 그래서 클라이언트와 서버에서 개발해야 할 내용이 명확해지고, 의존성이 줄어든다.
- 계층형 구조 rest 서버는 다중계층으로 구성될 수 있다. 로드벨런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 proxy, 게이트웨이 같은 네트워크 기반의 중간매체를 사용 가능하다.
4. Rest API 디자인 가이드
- uri는 정보의 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP method로 표현한다.
-
uri는 정보의 자원을 표현해야 하지, 행위를 표현하면 안된다.
Get /members/delete (x)
DELETE /members/1 (o) -
주의 사항
- 슬래시는 계층관계
- 마지막에는 / 사용하지 않는다.
- (하이픈)은 uri 가독성을 높이기위함
- _(밑줄)은 사용하지 않는다.
- uri 경로에는 소문자가 적합
- 확장자는 경로에 포함하지 않는다.
- 메시지 바디에 대한 포맷위한 확장자는 accept header에 적는다.
-
리소스 간의 관계 표현
/리소스명/{리소스Id}/관계가 있는 다른 리소스명
ex) get /users/{userId}/devices
-
collection과 document
-
collection,document는 모두 리소스, uri에 표현됨
-
collection은 document의 집합, 객체들의 집합
-
collection은 복수로, document는 단수로 사용한다면 이해가 쉬움
ex) /countries/korea/cities/seoul
/sports/soccer/player/7
-
5. http 응답 코드
잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 합니다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있음
출처: https://meetup.toast.com/posts/92
재미있는글
Rest를써야할까? : http://haah.kr/2017/06/12/rest-the-big-lie/
rest vs http: https://www.inflearn.com/questions/126743
