[면접준비] REST 장, 단점

이전에도 REST API 에 대해 정리를 했는데, REST API 장, 단점 중심으로 작성을 해보려고 한다.

먼제 REST 는 웹에 존재하는 자원에 대해 고유한 URI 값을 부여하는 방법론이다. 각각의 자원에 대한 고유한 URI와 자원에 대한 처리 방식인 METHOD를 가지고 있다.

흔히, 'REST 하다'는 것은 아래에서 제시하는 REST의 특징을 얼마나 잘 반영하느냐에 결정된다. (이전 포스팅 : https://lkhlkh23.tistory.com/78)

(1) Unirom Interface

자원에 대해 통일된 방식을 통해 처리하기 때문에 HTTP 표준만 준수하면 IOS, JAVA 등 다양한 언어에 종속받지 않고, 모든 환경에서 사용이 가능하다. (Loose Coupling)

 - Self Descriptive

    REST API에서 전달하는 메세지만 봐도 REST API가 원하는 바를 쉽게 이해할 수 있다. 별도의 주석이나 문서가 없어도 파악이 가능할 정도로 가독성이 높다.

 - Hateoas

   링크를 이용해서 애플리케이션의 상태를 관리하기 위한 매커니즘. 왜 써야할까?!

   만약에, 클라이언트가 서버에 요청하는 URL이 변경되면 어떻게 해야할까?! 그렇다면 해당 서버와 연관된 모든 클라이언트가 변경해야 하는 문제가 발생한다!

   이럴경우, Hateoas가 문제의 부담을 줄어들 수 있다. Hateoas를 적용해서 얻은 결과는 아래와 같다.

   rel에서는 관계를 나타내며, links는 해당 자원의 위치를 나타낸다. 그러면 이 상태에서 클라이언트가 수정없이 자원을 얻을 수 있을까?!

   나라면, 자원의 관계가 self일때 href를 redirect할거 같다. 이렇다면, 수정되지 않았다면 불필요하지만 한번더 요청을 할 수 있고, 수정되었다면 redirect를 통해 원하는

   데이터를 얻을 수 있다. 참고로 HTML 포맷으로 전송하게 되면 Hateoas를 준수하기가 상대적으로 쉽다(<a> 태그를 활용하면) 그러나 HTML보다 JSON 을 활용하는 이유가

   무엇일까? 다양한 클라이언트들이 웹 브라우저라는 보장이 없다. 안드로이드면 어떻할려고! 

 - resource of identification

   이것은 URL을 명확하게 명시함으로써 자원을 식별할 수 있게 하라는 것을 의미

 - 메세지를 통한 리소스 조작

   자원에 접근하는 Method Type을 명확하게 명시

(2) Stateless - HTTP 프로토콜을 사용하면

서버에서는 클라이언트의 이전 요청을 저장하지 않고, 모든 요청에 대해 독립적으로 처리한다. 

(3) Cacheable

HTTP 프로토콜을 사용하기 때문에 HTTP가 가지고 있는 인프라적 특성인 웹 캐시 사용이 가능하다. 웹 캐시를 통해 이전에 처리했던 데이터에 대해 서버를 거치지 않고

캐시를 통해 정보를 제공할 수 있기 때문에 빠른 응답을 기대할 수 있다. 특히, 웹에서 가장 많이 사용하는 연산은 GET이기 때문에 웹 캐시를 활용하면 좋다.

(4) Client-Server

클라이언트는 서버에게 요청을 하고, 서버는 클라이언트에게 요청 처리한 결과를 응답을 하는 구조로, 각각의 역할이 명확하게 나누어져 있다.

(5) layered System

HTTP 프로토콜을 사용하면, Client - Server 사이의 중간 단계의 기능을 활용할 수 있다. 예를들어, 로드밸런싱, 캐싱 기능 등을 활용할 수 있다.

결국 위 5가지 특성 모두 HTTP가 가지고 있는 특성이며, HTTP 프로토콜을 사용하기 때문에 어떻게 보면 당연한 결과일지도 모른다.

REST API의 특성은 곧 장점이 된다.

(1) 쉬운 사용법

Rest의 Self Descriptive 특성이 있기 때문에 메시지만 봐도 REST API가 원하는 바를 쉽게 파악할 수 있다. 별도의 문서를 확인하지 않아도, 가독성을 통해 명확하게 의도하는

바를 쉽게 파악할 수 있다. 또한,  URI 접근에 대한 통일적인 인터페이스를 사용하기 때문에 플랫폼에 독립적이다.

(2) 클라이언트 서버 사이의 완벽한 역할 분할

Clien-Server 특성 덕분에 각 역할들이 명확하게 분할 되어있다. 또한, Stateless 덕분에 서버는 이전 요청에 대한 문맥을 저장할 필요 없고, 저장할 필요가 있을 경우에는 

클라이언트에서 저장을 하면 된다.

(3) 명확한 명세

REST API는 헤더에는 URI와 처리방식, 바디에는 실제 데이터를 구성할 수 있는 기능을 제공한다. 그리고 특정 메소드의 세부적인 표현을 JSON, XML 등 다양한 언어를 

이용하여 작성할 수  있다는 장점뿐만 아니라, 간결하게 표현함으로써 가독성을 높일 수 있다는 특성 또한 가지고 있다.

결국 정리하자면, 

 - 자원에 대한 통일된 조작 방법을 통해 플랫폼 독립적

 - 클라이언트와 서버의 명확한 역할 분할

 - 헤더에 URI와 처리방식, 바디에는 데이터를 넣고, JSON, XML을 이용하여 세부적인 표현을 작성함으로써 가독성 증가, 별도 학습없이 쉽게 사용 가능

그렇다면 단점도 존재하지 않을까?

(1) METHOD 처리방식의 제한

자원 처리 방식에 대해 정의하는 방식이 제한적이다. POST, GET, PATCH, HEAD, PUT, DELETE 를 제공하고 있는데, 만약 메일 보낸다고 한다면 어떤 메소드로 처리하는 것이

맞을까? 무언가를 생성하고 있는가? 데이터를 가져오는가? 수정하는가? 삭제하는가?

(2) 표준의 부재

공식화된 API 가이드가 존재하지 않으며, 개발자들이 쌓아올린 약속들을 바탕으로 구성되었고, 사용되고 있다. 표준이 없다는 것은 아직 더 발전하고 확장될 수 있다는 가능성을

의미하지만, 한편으로는 명확한 표준이 필요하다.