REST
Representational State Transfer의 약자.
자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.
RESTful?
RESTful은 일반적으로 REST 아키텍처를 구현하는 웹 서비스를 나타내는 용어이다.
REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다.
REST API?
REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻한다.
쉽게 요약하자면 http 요청을 보낼때 어떤 URI에 어떤 메서드를 사용할지, 그리고 그외의 사항들에 대해서 널리 지켜지는 일종의 규약이라고 할 수 있다. 특정한 기술이 아니라 형식이기 때문에 특정 기술에 대한 의존성은 없다.
REST 구성
자원(Resource) - URI
행위(Verb) - HTTP METHOD
표현(Representations) - 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보
REST 의 특징
-
Uniform (유니폼 인터페이스): Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
-
Stateless: HTTP와 마찬가지로 Stateless한 특성을 갖는다.
-
Cacheable (캐시 가능): REST는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능도 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
-
Self-descriptiveness (자체 표현 구조): REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다.
-
Client - Server 구조: REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어든다.
-
계층형 구조: REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
REST API 중심 규칙
-
URI는 정보의 자원을 표현해야 한다. 따라서 리소스명은 동사보다는 명사를 사용한다.
또한 행위에 맞는 HTTP method를 선택해야 한다. -
예를 들어 어떤 영화의 정보를 보여주기 위해선
/view-movies/1 보다는
/movies/1 이 좋다
1번 회원의 정보를 삭제한다면
GET /members/delete/1 보다는
DELETE /members/1 이 적절하다 -
HTTP 메서드중 POST, GET, PUT, DELETE 이 4가지를 가지고 CRUD를 할 수 있다.
-
GET: 해당 리소스를 조회한다. 조회만 하기 때문에 body에 내용이 없어도 상관없다. GET을 통해 뭔가 추가하거나 수정하면 안된다.
ex)영화 타이타닉의 출연진 정보 조회:
GET /movies/titanic/actors -
POST: 해당 URI를 요청하면 리소스를 생성한다.
ex)신규 회원가입:
POST /users -
PUT: 해당 리소스가 있으면 대체하고 없으면 생성한다. POST와는 다르게 특정 리소스를 지정해야한다.
ex)123번 회원의 주소 수정:
PUT /users/123/address -
DELETE: 해당 리소스를 삭제한다. GET과 비슷하게 body가 없다.
ex)123번 회원정보 삭제:
DELETE /users/123
URI 설계 시 주의할 점
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
- 하이픈(-)은 URI 가독성을 높이는데 사용한다.
- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함시키지 않는다.
