# API : REST [2/2]

지난 포스팅에 이어서 REST API에 대한 설명을 진행한다.

6. RESTful

REST API의 설계 의도를 명확하게 지켜주는 것을 'RESTful하다'고 한다. 뭔가 멋있는 의미처럼 보이지만, 실제로도 그러하다.
RESTful한 API는 각 구성요소들의 역할이 명확히 분리되어 있음 을 의미한다.
URI는 각 리소스(자원)를 정확하고 인식하기 용이하게 표현하도록 하며, 자원에 대한 행위(메소드)를 HTTP 메소드를 이용하여 Uniform하게 정의한다.
기타 페이로드 부분은 JSON, XML 등을 이용하여 별도로 정의할 수 있다.

일반적으로 RESTful한 API 설계를 위해 가장 중요한 부분을 꼽자면 'URI의 명확한 정의'를 들 수 있다. 설계 원리는 다음과 같다.

6.1. 슬래시(/) : 계층 관계 표시

예를 들어 http://www.homepage.com/users/newuser 라는 URI가 있다고 하자.
여기서 http://www.homepage.com이라는 호스트(서버)와 users는 계층 관계가 된다.
users는 다양한 사용자 리소스를 모아 놓은 컬렉션이 되는데, users라는 컬렉션 하위에 newuser를 포함한 다양한 유저 리소스가 존재할 수 있다.
결국 users와 newuser 또한 계층 관계가 되며, 이러한 계층 관계는 슬래시(/)를 이용하여 표현된다.

URI에서는 계층 관계를 표현할 때, 약속된 문구를 사용하는 것을 권장한다.
여러 리소스들의 집합을 의미하는 컬렉션의 경우 복수(-s)를 사용하도록 하며, 각 리소스 엘리먼트(element)들은 단수를 사용하여 가독성을 높이도록 한다.

결국 모든 컬렉션은 하위 엘리먼트들을 갖고 있으며, 각 하위 엘리먼트들은 컬렉션이 될 수 있다는 의미가 된다. 그리고 URI의 최종 목적지는 엘리먼트가 되어야 하는데, 이는 마지막에 /로 끝나지 않아야 한다는 것을 뜻한다.

6.2. 가독성의 중요성

가독성을 위해 가장 중요한 것은 엘리먼트를 표현할 때 '명사'를 사용하는 것이다.
특히 Under Score(_)를 사용하는 행위는 꼭 자제해야 한다. 이는 특정 폰트나 문자에서 명확하지 못한 가독성을 보일 수 있기 때문이다.
또한 URI는 호스트를 제외한 나머지에 대해 소문자를 사용하는 것이 좋다. URI는 RFC3986에서 대소문자를 구별하도록 정의하였다. 이에 명확한 정의를 위해서 소문자로 통일하는 것이 좋다.  (예를 들어 Users와 users는 명백히 다른 컬렉션이 된다)

6.3. 파일 확장자는 URI에 포함하지 않는다.

http://www.homepage.com/images/main.jpg

라는 파일이 있다고 가정하자. 위는 파일의 확장자를 같이 포함하고 있다.
jpg의 경우에는 매우 일반화된 확장자이기 때문에 큰 문제가 되지 않을 수도 있다. 하지만 alz, hwp와 같은 확장자의 경우에는 외국 유저들 사이에서 문제가 될 수 있다.
만약 확장자를 써야한다면, 확장자에 대한 설명까지 URI를 통해 알 수 있도록 하는 것이 좋다. 하지만 이러한 경우에는 가독성의 문제가 생길 수 있으므로 확장자는 되도록 포함하지 않는 것이 좋다.

6.4. 명사 위주의 URI 구성

GET http://www.homepage.com/users/delete-oldman

이라는 메소드가 있다고 하자. 이러한 경우 GET 메소드를 이용하여 특정 리소스를 호출하는 내용이지만, 전체적인 맥락을 보면 오래된 사용자를 지우는 메소드처럼 보일 수 있다.
URI에 동사를 사용하면 모호성이 존재할 수 있게 된다.

이 외에도 다양한 설계 방침이 존재한다. 명확한 문법이나 표준이 존재하지 않기 때문에, 개발자 및 사용자들로 하여금 혼란을 방지하기 위한 일련의 '약속'들이라고 보는게 좋다.

7. REST API의 장점

7.1. 사용이 쉽다.

REST API의 가장 큰 장점이다. REST API 메시지를 단순히 읽는 것 만으로도 메시지가 의도하는 바를 파악할 수 있을 정도로 쉬운 이해가 가능하도록 한다.
또한 HTTP 인프라를 그대로 사용하므로, REST를 사용하기 위한 별도의 인프라 구축이 필요없다.
더 나아가 Stateless한 특징 때문에 수행 컨텍스트가 독립적으로 진행된다. 결국 이전에 서버(호스트)에서 진행된 내용들에 대해 알 필요가 없고, 이제까지 진행된 히스토리에 대해 알 필요 또한 없으므로, 해당 URI와 메소드 자체만 독립적으로 이해하면 된다.

7.2. Client-Server의 명확한 분리

클라이언트는 REST API를 이용하여 서버와 정보를 주고받는다. 서버 입장에서는 클라이언트의 수행 컨텍스트를 유지할 필요가 없다. 왜냐하면 Stateless하니까.
결국 클라이언트와 서버는 우리 식으로 표현하자면 '니들일은 니들이 알아서 해'식으로 동작한다. 각자의 역할이 명확하게 분리되어 있고, 세션 상대방의 상태에 대해 신경쓸 필요가 없다.
이러한 장점은 더 나아가 플랫폼의 독립성까지 확장될 수 있다. HTTP 프로토콜만 서비스하면 되므로, 다양한 플랫폼에서 쉽게 서비스를 개발할 수 있게 된다. (리눅스 웹 서버에서 윈도우 플랫폼 기반의 웹 브라우저를 동작시킬 수도 있다)

7.3. 원하는 데이터 표현 사용 가능

REST API는 헤더 부분에 URI 처리 메소드를 명시함으로써, 필요한 실제 데이터를 Body(Payload)에 표현할 수 있도록 구성하였다. 이는 JSON, XML 등 다양한 언어를 이용하여 내부 표현 문구를 작성할 수 있다는 장점 뿐만 아니라, 간결한 헤더 표현을 통한 가독성 향상의 장점 또한 갖게 된다.

8. REST API의 단점

하지만 모든 기능이 '장점만 가질 수는 없다.' REST API 또한 다음과 같은 단점을 포함하고 있는데, 하나씩 살펴보자.

8.1. HTTP 메소드의 한계

REST API는 HTTP 메소드를 사용하여 URI 행위를 정의한다. 이는 간단한 형태의 메소드만을 제공하게 되는 한계를 보일 수 있다. 예를 들어, 메일을 보내는 등의 복잡한(나름) 행위는 단일 메소드로 쉽게 구현하는 것이 어려울 것이다.

8.2. 표준의 부재

REST API는 위에서 설명하였듯이 표준이 존재하지 않는다.
이는 관리가 어렵고, 좋은 API 디자인에 대한 가이드가 존재하지 않음을 의미한다. 또한 가이드 별로 적용되는 상황이 다르기 때문에, 모든 가이드가 적합하지 않다는 것을 나타내기도 한다.
한편으로는 그만큼 REST API가 무궁무진한 발전가능성이 존재하다는 것을 의미하기도 하는데, 이것은 단점과는 거리가 멀기 때문에 패스하기로..

참고 사이트

http://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=220986337770