REST

REST란 REpresentational State Transfer의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다. 이는 로이 필딩에 의해 소개되었으며 HTTP의 주요 저자였던 로이 필딩이 웹 설계의 우수성에 비해 제대로 사용되지 않는 모습을 보고 웹의 장점을 최대한 활용할 수 있는 아키텍처로 REST를 발표했다고 한다.

REST는 위에서 언급한 것처럼 자원(Resource)를 이름으로 표현(Representations)하며, 해당 자원의 상태를 주고 받는 모든 것을 의미한다.

여기서 자원은 URI를 의미하고, 자원에 대한 행위, 즉 주고 받는 모든 것은 HTTP Method라는 이름으로 표현한다. HTTP Method는 익히 알고 있는 GET, POST, PUT, DELETE 와 같은 것이 있다.

이 REST는 몇 가지 특징을 가지고 있다.

1. Uniform Interface

URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다. 
이는 아마 GET, PUT, POST, DELETE 등의 인터페이스로 한정지어서 해당하는 것을 의미하는 것 같다.

2. Stateless

REST는 무상태성의 성격을 가진다. 즉, 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다는 것이다. 세션 정보나 쿠키 정보 등을 별도로 저장하지 않고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 되는 것이다. 이를 통해 서비스의 자유도가 높아지고, 서버에서 불필요한 정보를 관리하지 않게 되어 구현이 단순해진다.

3. Cacheable

REST는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용 가능하다. 따라서 HTTP가 가진 캐싱 기능을 적용할 수 있따. HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 나 E-Tag를 이용하면 캐싱 구현이 가능하다.

4. Self-descriptiveness

REST는 REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

5. Client-Server 구조

REST 서버는 API 제공을, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

6. 계층형 구조

REST 서버는 다중 계층으로 구성될 수 있으며, 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고,
PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.

 

HTTP METHOD의 알맞은 역할

POST  - POST를 통해 해당 URI를 요청하면 리소스를 생성한다.

GET - GET을 통해 해당 리소스를 조회한다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.

PUT - PUT을 통해 해당 리소스를 수정한다.

DELETE - DELETE를 통해 리소스를 삭제한다.

 

URI 설계 시 주의할 점

1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.

ex) http://rollinghoney.com/login

2. URI 마지막 문자로 슬래시를 포함하지 않는다.

ex) http://rollinghoney.com/login/

3. 하이픈은 URI 가독성을 높이는데 사용한다.

4. 밑줄(_)은 사용하지 않는다.

5. URI 경로에는 소문자가 적합하다.

6. 파일 확장자는 URI에 포함시키지 않는다.

 

HTTP 응답 상태 코드

1xx - Information(정보 제공)

100 - 계속 진행

101 - 프로토콜 전환

102 - 처리중

2xx - Success(성공)

200 - 클라이언트 요청을 정상적으로 수행함

201 - 클라이언트가 어떠한 리소스를 생성 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)

203 - 신뢰할 수 없는 정보 
응답 헤더가 오리지널 서버로부터 제공된 것이 아닐 때

204 - 콘텐츠 없음
처리를 성공하였지만, 클라이언트에게 돌려줄 콘텐츠가 없을 때

205 - 콘텐츠 재설정
처리를 성공하였고, 브라우저 화면 리셋

206 - 일부 콘텐츠
콘텐츠 일부만 보냄

207 - 다중 상태
처리 결과의 스테이터스가 여러 개

3xx - Redircetion(리다이렉션)

300 - 여러 선택 항목
선택 항목이 여러 개

301 - 영구 이동
지정한 리소스가 새로운 URI로 이동
클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드
(응답 시 Location Header에 변경된 URI를 적어 줘야 한다.)

303 - 다른 위치 보기
다른 위치로 이동

307 - 임시 리다이렉션
임시로 리다이렉션 요청이 필요

4xx - Client Error 

400 - 잘못된 요청
클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드

401 - 권한 없음
클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 경우 사용하는 응답 코드
(ex) 로그인 하지 않은 유저가 로그인 이후 요청 가능한 리소스를 요청했을 때)

403 - 금지됨
유저 인증 상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 코드
(403보다는 400이나 404를 사용할 것을 권고한다. 403 자체가 리소스가 존재한다는 뜻이기 때문)

404 - 찾을 수 없음
지정한 리소스를 찾을 수 없다.

405 - 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드

5xx - Server Error(서버에러)

500 - 내부 서버 오류
서버에 문제가 있을 경우 사용하는 응답 코드 

501 - 구현되지 않음
요청한 URI의 메소드에 대해 서버가 구현하고 있지 않다.

502 - 불량 게이트웨이
게이트웨이 또는 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받았다.

 

이외에도 다양한 응답 상태가 존재하지만 주로 사용되는 것은 위와 같다.

 

REST API 제대로 알고 사용하기 : NHN Cloud Meetup

REST API 제대로 알고 사용하기 : NHN Cloud Meetup