Rest Api 정의/특징/설계 가이드라인

1. Rest Api

Rest는 Representational State Transfer 용어의 약자로서 2000년도에 로이필딩에 의해 처음 소개되었습니다. 여기서 Rest는 웹에 존재하는 모든 자원에 고유한 

URI를 부여해 활용하는 방법론입니다. 그리고 API는 웹 애플리케이션에서 다른 서비스에 요청을 보내고, 응답을 받기 위해 정의된 명세를 의미합니다.

결국 정리하자면, Rest Api는 Rest 아키택처 또는 특징에 맞추어 다른 서비스에 요청/응답을 위한 인터페이스를 의미한다.

Rest 는 자원(URI), 행위(HTTP METHOD), 표현(Respresentation) 으로 구성되 있습니다. 

여기서 URL, URI의 차이점을 간단히 비교하자면, URI는 인터넷상에서 자원을 나타내는 유일한 주소이고, URL은 자원이 어디있는지를 알려주기위한 규약이다.

여기서 URI는 '유일한' 이라는 키워드가 붙어있다. 이 부분이 가장 큰 차이점이라고 할 수 있다. 예를들어 'http:www.naver.com/doc?id=1'이라는 경로는

쿼리를 통해 id가 1인 문서를 보여주는 주소라고 하자. 여기서 doc는 쿼리의 id값을 통해 여러가지 문서가 출력될 수 있다. 여기서 'http:www.naver.com/doc' 가

자원의 위치를 표현하는 URL에 해당되고, 쿼리를 통해 123에 해당되는 문서는 자원의 유일한 주소를 나타내기에 URI에 해당된다.

간단하게 보면, URI가 URL을 포함하는 상위개념이다. 

다시 본론으로 돌아가서, Rest Api의 6가지 특성을 정리해보자

2. Rest Api 특성

 (1) Uniform Interface

  URI로 지정한 자원에 대한 조작을 통일된 인터페이스로 조작하여 수행하는 것을 의미한다. 결국은 HTTP 표준만 준수한다면, IOS, Java, 등 다양한 언어에

  종속받지 않고, 모든 환경에서 쉽게 사용이 가능하다. (Loose Coupling) 그리고, 최근에는 XML 보다 JSON을 이용한 메세지 포멧을 주로 활용한다.

  그 이유는 JSON이 더 간결하고, 쉽게 작성할 수 있기 때문이지 않을까?

 (2) Stateless

  Rest Api는 세션이나 쿠키를 통해 상태정보를 저장하지 않는다. 단순히, 요청에 대한 처리만 수행하기 때문에 자유도가 높고, 불필요한 정보를 관리하지 않기 

  때문에 구현이 간단하다.

 (3) Cacheable

  Rest Api는 HTTP 웹 표준을 준수하기 때문에 HTTP가 가지고 있는 장점을 이용할 수 있다. 그중 하나가 캐싱 기능이다. 

  대부분의 시스템의 트랜잭션 select 쿼리를 이용한 데이터 조회가 대부분이기 때문에 캐싱을 활용하면 성능면에서 많은 장점을 기대할 수 있다.

  Last-Modified, ETAG를 이용하여 캐싱을 구현할 수 있다. 아래 이미지를 보면 클라이언트는 서버에 GET 방식으로 데이터를 요청하고 응답을 받았다.

  그리고 시간이 흘러 같은 요청을 보냈고, 서버는 Not Modified 304 Status를 반환하였다. 그러면 클라이언트는 데이터가 변하지 않았다는 것을 인식했기

  때무에 캐싱에서 이미 가져온 데이터를 가져올 수 있다. 

 (4) Self-Descriptiveness

  Rest Api는 메세지만 봐도 직관적으로 구조 파악이 가능하다.

 (5) Client - Server

  서버는 API 제공, 클라이언트는 컨텍스트(로그인, 세션) 관리하는 구조로 각각의 역할이 명확하게 분리되어있다. 서로에 대한 의존성이 낮다.

3. Rest Api 설계 주의점

 (1) 슬래시(/) 구분자는 게층관계를 나타낼때만 사용하고, URI 마지막에는 슬래시(/)를 포함하지 않아야 한다. 포함할 경우 오류 발생

 (2) 하이픈(-)을 사용하되, 언더바(_)는 URI 표현에 사용하지 않는다.

 (3) URI에는 파일의 확장자는 포함하지 않는다.

 (4) URI 경로에는 소문자를 사용한다.

 (5) URI 자원을 나타낼때는 동사보다는 명사를 사용하고, 명사를 사용할 때 복수형을 나타낸다. 예) GET /questions/1 : 질문번호 1를 가져오는 URI

 (6) 자원에 대한 행위는 HTTP METHOD를 이용한다. 예) DELETE /questions/1 : 질문번호 1를 삭제하는 URI

4. 기타 내용 추가

무상태와 상태의 차이는 무엇일까?!  상태값을 서버에서 관리하면 Statefule, 상태값을 서버에서 관리하지 않으면 Stateless 하다.

로그인을 하면 서버는 쿠키의 JSESSIONID를 등록해서 세션으로서 상태를 관리한다. 이렇더라면 Stateful 하다고 할 수 있다.

그러나 만약에 쿠키의 JSESSION에서 logined=true 를 통해 상태를 확인한다면, 서버는 별도의 상태를 관리하지 않는다. 이렇더라면 Stateless 하다고 할 수 있다.

HTTP 무상태라고 해서 장점이라면, 서버가 n대라고 했을 때, 상태에 대한 제어가 없기 때문에 어느 서버에서든 요청을 처리할 수 있다.

그러나 만약에 상태를 유지한다고 하면, 나의 요청에 대한 상태를 특정 서버에서 관리하고 있기 때문에 반드시 그 서버가 처리해야만 한다.

그렇기 때문에 서버의 확장에 많은 제약사항을 줄 수 있다. 그래서 무상태 좋은 것 같다!!