RESTful이란?

RESTful이란?

REST는 Representational State Transfer의 약자로 웹의 장점을 최대한 활용 할 수 있는 아키텍처이다.

최근 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 하기때문에 REST 아키텍처는 HypermediaAPI의 기본을 충실히 지키면서 범용성을 갖는다.

REST의 특징

1.Uniform(유니폼 인터페이스)

• Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.

2.Stateless(무상태성)

• 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.

• 세션이나 쿠기등을 별도로 관리하지 않기 때문에 API서버는 들어오는 요청만 단순 처리되어 서비스의 자유도가 높아져 불필요한 정보를 관리하지 않음으로써 구현이 단순해 진다.

3.Cacheable(캐시 처리가능)

• REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하는것이다.
• HTTP가 가진 캐싱 기능을 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified, E-Tag를 이용하면 캐싱구현이 가능하다.

4.Self-descriptiveness(자체 표현 구조)

• REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어있다는 것이 장점이다.

5.Client - Server Architecture(클라이언트 - 서버 구조)

• REST 서버는 API를 제공하고 클라이언트의 경우 사용자 인증이나 Context(세션, 로그인정보)등을 직접 관리하는 구조이며, 각각의 역할이 확실하게 구분된다.
• 서로간의 의존성이 줄어든다.

6.계층형 구조

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

REST 구성

• 자원(Resource) - URI
• 행위(Verb) - HTTP Method(GET, PUT, POST, DELETE 등)
• 표현(Representations)

REST API 디자인 가이드

• URI는 Resource를 표현해야한다.
• Resource에 대한 행위는 HTTP Method로 표현한다.

1.REST API 중심 규칙

1.1 URI는 정보의 자원을 표현해야한다.

GET /course/insert/inform  (x)
GET /course/inform  (o)

• HTTP Method의 행위가 URI 표현으로 들어가서는 안된다.

1.2 자원에 대한 행위는 HTTP Method로 표현해야한다.

DELETE /members/1

• HTTP Method로 CRUD를 표현 할 수 있다.

2.URI 설계 시 주의 할 점

2.1 소문자를 되도록이면 사용하자.

• 예를 들어 test.com의 자원(Resource) Test와 test가 있지만 대소문자에 따라 구분하기 때문에 다른 자원(Resource)으로 인식하게되므로 소문자로 통일하자.
• RFC 3986(URI 문법형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하고 있다.

http://test.com/Test
http://test.com/test
-- 서로다른 Resource 이다.

2.2 하이픈(-)은 URI가독성을 높이는데 사용하자.

• 경로(Path)에 띄어쓰기가 들어가는 경우 %20이 들어가 가독성이 매우 떨어진다.
• 하이픈(-)을 사용하여 띄어쓰기를 대체하면 가독성을 높일 수 있다.

2.3 확장자를 사용하지 말자

• REST API에서는 확장자를 사용하지 않으면 자원(Resource)을 다루는 데 더 유연해 진다.
• 확장자 대신에 Accept Header를 사용하여 확장자에 대한 문제를 해결 할 수 있다.

http://test.com/test.jpg   (x)
http://test.com/test   (o)
GET /test HTTP/1.1
Host: test.com
Accept: image/jpg

3.자원을 표현하는 Collection과 Document

• Document는 단순한 문서와 같은 존재이다.
• Collection은 문서들의 집합이다. 객체들의 집합 같은 존재이다.

http://test.com/citys/seoul/gangnam

• 위 예제 중 citys가 Collection에 해당되며 복수로 표현을 하고 있는점이 특징이다.

4.HTTP 응답코드

4.1 성공(Success)

상태코드	내용
200	정상적으로 수행
201	자원(Resource) 생성 요청. 성공적으로 수행됨.

4.2 클라이언트 에러(Client Error)

상태코드	내용
400	클라이언트 요청이 부적절할 경우 응답코드
401	클라이언트가 권한이 없는 자원(Resource)를 요청하였을 때 응답 코드
403	보호되는 자원(Resource)를 요청하였을 때 응답코드
405	클라이언트가 요청한 리소스에서는 사용 불 가능한 Method를 이용했을때 응답코드

4.3 기타

상태코드	내용
301	클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 응답 코드
500	서버에 뭔가 문제가 있을 때 사용하는 응답코드

Reference

• http://meetup.toast.com/posts/92

• https://spoqa.github.io/2012/02/27/rest-introduction.html