탄생배경
- 컴퓨터 과학자인 로이 필딩(Roy Fielding) 박사가 2000년에 자신의 박사학위 논문에서 처음으로 소개했습니다. 웹의 장점을 최대한 활용할 수 있게 하기 위해 만들었다고 합니다.
REST API란?
- Representational State Transfer의 약어로서 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미.
- HTTP의 장점을 최대한 활용할 수 있는 아키텍처.
특징
- 서버 클라이언트 구조
- 자원이 있는 쪽이 Server, 요청하는 쪽이 Client가 된다.
- REST Server - API를 제공하고 비즈니스 로직 처리 및 저장을 책임.
- Client - 사용자 인증, context관리.
- ⇒ 역할이 구분되어 서로 개발해야 할 것이 구분되어지고 서로간의 의존성도 줄어듦.
- Stateless(무상태성)
- 작업을 위한 상태정보를 따로 저장하고 관리하지 않음.
- 그때그때 들어오는 요청만 처리.
- ⇒ 구현이 단순함.
- Cacheable(캐시 가능)
- 웹 표준 프로토콜을 사용하므로 기존의 인프라를 사용할 수 있음.
- HTTP가 가진 캐싱 기능 적용 가능.
- 계층형 구조
- REST 서버는 다중 계층으로 구성될 수 있으며 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 프록시, 게이트웨이 같은 중간매체 사용 가능.
- Uniform Interface
- URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행.
필요한 이유?
- 혼자 개발하면 요청방식을 자기 마음대로 작성해도 문제 없지만 협업을 하게 된다거나 개발하던 것을 인계하는 상황이 생길 경우, 다른 사람들은 그 코드가 의미하는 바가 무엇인지 추론이 어려움. 그래서 RESTful하게 만든 API는 요청파악이 훨씬 수월함. ⇒ 유지보수와 운영 편리.
단점
- 표준이 존재하지 않음. 규칙을 알아서 정해야 함.
- 메소드 형태가 제한적.
REST API 설계 규칙
/로 계층 관계를 구분한다.- URL마지막에
/로 마무리 하지 않는다./는 유일한 식별자로 사용되어야 함.
- 하이픈(
-)은 URL가독성을 높이는데 사용한다. - 밑줄(
_)은 URL에서 사용하지 않는다.- 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않음.
- URL경로에는 소문자가 적합.
- 파일확장자는 URL에 포함시키지 않는다.
- REST API는 메시지 바디 내용의 포맷을 나타내기 위한 파일확장자를 URI에 포함시키지 않음.
- Accept header를 이용.
- 리소스의 경우 연관관계가 있는 경우에 사용한다.
- /리소스명/리소스ID/관계가 있는 다른 리소스명
Reference
