REST Service에 대하여

REST API란?

Representational State Transfer

웹을 좀 더 효율적으로 사용하기 위한 아키텍처

 

REST 구성

- 자원(URI)

- 행위(METHOD)

- 표현

 

REST 특징 ( 아직 모호한 개념 )

1) uniform interface : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

2) stateless (상태없음) : 작업을 위한 상태가 따로 없음. API는 들어오는 요청만 단순히 처리.

3) Cacheable(캐시가능): HTTP가 가진 캐싱 기능이 적용됨, HTTP프로토콜에서 사용하는 헤더(Last-modifed, E-tag)를 이용하여 캐싱 구현 가능

4) Self-descriptiveness(자체 표현 구조) : REST API 만 보고도 쉽게 이해할 수 있는 자체적으로 표현능력도 있음.

5) Client-Server 구조 : 서버는 API제공, 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인정보) 등을 직접 관리하는 구조, 각각 역할이 확실히 구분된다.

6) 계층형 구조 : 다중 계층으로 구성될 수 있으며, 로드밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있음. 프록시나 게이트웨이 같은 네트워크 기반의 중간매체를 사용 가능

 

REST 설계 가이드

1) URI는 정보의 자원을 표현해야한다

2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

3) 마지막 문자 슬래시는 작성하지 않는다.

4) 너무 긴 리소스의 경우 하이픈(-)을 사용하여 의미상 구분하여 가독성을 올린다(언더바(_)는 사용 안함)

5) 소문자가 적합

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

7) 컬렉션과 도큐먼트의 개념에 따라 단/복수를 지킨다.

8) 리소스명은 동사보다 명사를 사용

• GET /members/delete/1/ ---(X)
• DELETE /member/1 ---(O)
• http:// restapi.example.com/sports/soccer/players/13 ---sports : 컬렉션, soccor : 도큐먼트, players : 컬렉션, 13 : 도큐먼트
• GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)

9) 물리적 URLs를 사용하지 마라.

• 실제 파일의 경로 : http://www.acme.com/inventory/pro​duct003.xml​
• 실제 파일을 포함하지 않는 논리적 경로 : http://www.acme.com/inventory/product/003

10) 데이터가 너무 많으면 paging을 해라

11) 응답은 정제해서 보내라. 응답을 수정하지 마라

12) GET 요청은 서버/DB의 상태 변화를 일으키지 않는다.

13) POST/PUT/DELETE 요청만 서버/DB의 상태를 변화시킨다. 

14) 클라이언트가 추가적인 액션을 위해 URLs을 구성하도록 두지말고, 실제 URLs를 응답에 담아라. 

예를 들어, 제품 리스트를 요청했을 때, 디테일 정보를 위한 링크를 제공한다고 할때

제품별 ID값들을 리턴하여, 다음과 같은 URL을 제공하지 말고, http://www.acme.com/product/PRODUCT_ID ---(X)

응답에 각각의 item 별로 실제 actual URL 을 제공해야한다. http://www.acme.com/product/001263 --- (O)

 

 

참고 http://rest.elkstein.org/2008/02/rest-design-guidelines.html

9. REST Design Guidelines