[Web] REST & RESTful

REST & RESTful

REST는 HTTP, 프로토콜이 아니다! REST는 일종의 가이드라인이다. 

REST API 는 REST 기반으로 서비스 API를 구현한 것

REST 원리를 따라르는 시스템(서비스)를 RESTful 이라고 한다. = REST API 를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다.

 

REST

REST는 Representational State Transfer의 약자로 분산 하이퍼 미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.

웹에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URL을 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다. → URL에 자원을 표현하는 것

HTTP URI 를 통해 자원을 명시하고 HTTP Method를 통해 해당 자원의 대한 CRUD Operation(생성, 조회, 변경, 삭제)을 적용한다.

 

HTTP URI(Uniform Resource Identifier)

URI는 네트워크 상에 존재하는 자원을 구분하는 식별자이다. URI은 URL, URN로 이루어져있으며 URL은 Where의 개념, 리소스의 구체적인 위치를 알려주고, URN은 What의 개념, 이름으료 표시되며 유일한 값이고 독립적이다.

URN, URL을 합쳐 하나의 식별자로 활용할 수 있다. (출처)

HTTP Method

HTTP 응답코드 메소드 정리 GET, POST, PUT, PATCH, DELETE, TRACE, OPTIONS

 

구성요소

1. Resource : 자원, HTTP URI
2. Verb : 자원에 대한 행위, HTTP Method
3. Representations : 자원에 대한 행위의 내용, HTTP Message Pay Load

 

REST 의 특징

6가지 제약 조건. 해당 특징을 지켜야 API가 RESTful로 간주될 수 있다.

1. 클라이언트 / 서버 구조 (Client-Server)
   
   자원이 있는 Server , 자원을 요청하는 Client의 구조
2. 무상태 (Stateless)
   
   HTTP는 Stateless 프로토콜 이므로 REST 역시 무상태성을 가진다. 클라이언트의 Content 를 서버에 저장하지 않는다.
   대신 세션의 상태에 대한 정보가 클라이언트에 저장됨
3. 캐시 처리 가능 (Cacheable)
   
   웹 표준 HTTP 프로토콜을 그대로 사용하므로 , 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다.
   클라이언트-서버 상호 작용을 간소화함
   
   ▷GET - 일반적으로 브라우저에서 cache 사용 가능
   ▷POST - 일반적으로 cache 사용 불가능. 하지만 Expires와 Cache-Control header를 이용하여 caching을 구현하여 응답할 수 있다.
   ▷PUT, DELETE - 해당 Request는 cache를 적용할 수 없다.
4. 계층화
   
   API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 사용자 인증 , 암호화 , 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연성을 줄 수 있다.
5. 인터페이스 일관성(Uniform Interface)
   
   URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
   HTTP 표준에만 따른다면 모든 플랫폼에 사용이 가능하다.
6. 자체 표현 구조
   
   동사(Method) + 명사(URI) 로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 알 수 있으며 REST API 자체가 매우 쉬워서 API 메세지 자체만 보고도 API를 이해할 수 있다.

 

REST API 에서 멱등성이란?

멱등성이란 어떤 대상에 같은 연산을 여러번 적용해도 결과가 달라지지 않는 성질이다.

REST API 에서 멱등성이란 응답이 다를 수는 있지만, 요청이 의도한 효과를 발휘할 때 멱등성이 유지됨을 의미한다. (여러번 요청을 보내도 요청에 의한 서버의 상태는 항상 같음)

Method	멱등성 보장	설명
GET	O	단순 리소스 읽어오는 행위이므로 여러번 수행해도 결과가 달라지지 않음
HEAD	O	GET과 마찬가지
PUT(자원 전체 갱신)	O	데이터가 없는 경우 생성될 수 있음, 이미 존재한다면 데이터는 수정된다. 요청에 담긴 리소스로 기존 리소스를 대체해버리기 때문에 여러번 수행해도 요청에 담긴 리소스가 변하지 않는 이상 연산 결과는 동일
DELETE	O	이미 존재하든, 존재하지 않든 그 데이터는 DELETE 요청을 보낸 시점에서 사라지게 된다. 즉, 우리가 요청한 사항은 이루어 졌음
POST	X	리소스를 새롭게 생성하는 행위이기 때문에 여러번 수행하게 되면 매번 새로운 리소스가 생성된 것이고, 연산을 수행한 결과가 매번 달라진다.
PATCH(자원의 일부 교체)	△	구현 방법에 따라 PUT 메소드처럼 보장될 수도 있고, 보장되지 않을 수도 있다. PUT 메소드처럼 리소스를 대체하는 행위가 아니기 때문에 요청을 어떤 방식으로 사용하는지에 대한 제한이 딱히 없기 때문이다. 1. 수정할 리소스의 일부분만 담에서 요청하는 경우에는 당연히 멱등성이 보장된다. 2. 하지만, 아래와 같은 경우 $increase필드 값은 증가시키고 싶은 속성을 의미하고, value 필드 값은 그 속성을 얼마나 증가시킬 것인지를 나타낸다. 이 경우 API가 호출될 때마다 나이가 1씩 증가하기 때문에 이 API는 멱등성을 보장하지 않는다. PATCH users/1 {   $increase: 'age',   value: 1, } 이런식으로 PATCH 메소드를 사용하는 경우는 못봤지만 스펙 상 제약이 없기 때문에 표준을 어기는 것은 아니다. 따라서 PATCH 메소드는 API를 어떻게 구현하느냐에 따라 멱등성을 보장할 수도 있고 아닐 수도 있다.

안전한 메소드 : GET, HEAD와 같이 서버측의 상태 정보를 변경하지 않는 메소드
멱등한 메소드 : 서버의 상태를 변경시킬 수도 있고, 시키지 않을 수도 있다. 다만, 우리가 요청한 사항은 에러가 나거나, 지연이 발생하지 않는 한 요청에 대한 서버의 상태는 항상 같다.

 

REST 장단점

장점

1. 쉬운 사용
   
   HTTP 인프라를 그대로 사용하므로 별도의 인프라 구축이 필요 없다.
2. 클라이언트-서버 역할의 명확한 분리
   
   클라이언트의 Context를 유지할 필요 없음
3. 특정 데이터 표현을 사용 가능
   
   헤더 부분에 URI 처리 메소드를 명시하고 필요한 실제 데이터를 body에 표현할 수 있도록 분리시킴. JSON, XML 등 원하는 Representation 언어로 사용 가능

단점

1. 메소드 한계
   
   HTTP Method로 URI를 표현하기 때문에 쉽지만 형태가 제한적임
2. 표준이 없음
   
   REST는 설계 가이드일 뿐 명확한 표준이 없다.

 

참고

• medium.com/@hckcksrl/rest%EB%9E%80-c602c3324196
• poiemaweb.com/js-rest-api
• https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
• https://sabarada.tistory.com/34
• https://oen-blog.tistory.com/211
• https://velog.io/@dion/HTTP-%EB%A9%94%EC%86%8C%EB%93%9C%EC%9D%98-%EB%A9%B1%EB%93%B1%EC%84%B1-%EA%B7%B8%EA%B2%8C-%EB%AD%94%EB%8D%B0