REST vs. RESTful

 

개발자라면 익숙한 REST API

하지만 누군가에게 설명하려면 막막한 느낌이 든다.

그리고 REST 와  RESTful은 분명 차이가 있지만,  현업에 종사하고 있는 개발자중에서도 이 차이점을 명확히 이해하고 있는 사람의 비율은 그렇게 높지 않을 것 이라 생각된다. 

 

이 글에서는 REST와 RESTful이 무엇인지 알아 볼것이다.  

 

---

 

상황을 가정해보자.

 

회사 동료가  회원의 데이터를 수정하는 기능을 제공하기위해 /update/member 와 같은 형태의 엔드포인트로 API를 제작했고, 리뷰를 요청했다.

팀동료들은 이 API를 보고 "REST 스럽지 않은데?" 라고 표현할것이다.

도대체 REST 가 뭐길래 그런 말을 하는 것일까?

 

일단, 일반적으로 개발자들은 RESTful API의 의미로 아래와 같은 뜻으로 이해 한다.

RESTful API 란? - URI 를 통해서 자원을 지정 - HTTP 메서드를 통해 자원에 대한 행위 표현 CREATE -> POST -> /order READ     -> GET    -> /order/100 UPDATE -> PUT   -> /order/100 DELETE- > DELETE -> /order/100

 

 

 그럼 RESTful API 가 위와 같은 뜻이면, 도대체 REST API와 는 무슨 차이 점이 있길래  ful(~스러운) 이라는 접미사를 붙여서 사용하는 것일까?

 

일단 그이유를 먼저 답하자면,

 

사실 REST API는 사실  모든 제약조건을 지키는 것은  엄청 까다롭기때문에, 어느 정도 규격을 완화 시켜서 사람들이 API를 만들고 있는 스타일이 RESTful API 이다.  (그래서 "~스러운 " 이라는 뜻의 접미사 ful 이 붙음)

 

 

 

---

그럼 이제 REST API를 만족 시키기 위해서는 어떻게 해야할까?

 

REST를 구성하는 스타일은 아래와 같다.

• Client-Server
• Stateless
• Cache
• Uniform Interface
• Layered System
• Code-On-Demand (optional)

 

위의 아키텍쳐 스타일들은 HTTP만 사용하여도 쉽게 달성할수있는 아키텍쳐 스타일이지만, Uniform Interface는 아래의 네가지를 달성해야한다.

• Identification of resources  - 자원의 식별
• manipulation of resources through represenations  - 메시지를 통한 리소스의 조작
• self-descrive messages  - 자기서술적 메시지
• hypermisa as the engine of appliaction state (HATEOAS)  - 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

 

네가지중  자원식별과, 리소스 조작은 일반적으로 알고있는 RESTful 과 일치하고   핵심은  아래의 두가지이다.

• Self-descriptive message
  • 설명 
    1. 메시지 스스로 메시지에 대한 설명이 가능해야 한다.
    2. 서버가 변해서 메시지가 변해도 클라이언트는 그 메시지를 보고 해석이 가능하다.
    3. 확장 가능한 커뮤니케이션
  • 해결 방법
    1. 미디어 타입을 정의하고 IANA에 등록하고 그 미디어 타입을 리소스 리턴할 때
       Content-Type으로 사용한다.
    2. profile 링크 헤더를 추가한다.
• HATEOAS
  • 설명
    1. 하이퍼미디어(링크)를 통해 애플리케이션 상태 변화가 가능해야 한다.
    2. 링크 정보를 동적으로 바꿀 수 있다. (Versioning 할 필요 없이!)
  • 해결 방법
    1. 데이터에 링크 제공 - 링크를  어떻게  정의할 것인가 것인가?  -> HAL
    2. 링크 헤더나 Location을 제공

 

 

 

위의 설명을 읽어도 사실 정확히 와닿지 않을 수 있다.

요약하자면, 응답 메시지만으로 자기 자신을 설명할수 있어야하고 (docs URL 을 같이 응답 하는 것과 같은 방식으로 ),

응답 메시지내용에 다음에 행동할 내용도 포함이 되어( 게시글 조회 API라면, 등록, 수정 등의 API의 URL 도 같이 응답) 있어야한다 라고 이해하면 될 것 같다.

 

 

RESTful API 예제  (REST API X)

- https://developers.naver.com/docs/login/payaddress-api/payaddress-api.md

- https://developers.kakao.com/docs/latest/ko/kakaotalk-social/rest-api

Kakao Developers

네이버 페이 배송지 정보 조회 API - LOGIN

REST API 예제

- https://docs.github.com/en/rest/issues/issues

 

네이버 페이 배송지 정보 조회 API - LOGIN

 

 

 

 

참조

https://wonit.tistory.com/454

HATEOAS를 모르면 당신이 알고 있는 REST API는 REST API가 아니라고 장담할게요.

https://ko.wikipedia.org/wiki/REST

REST - 위키백과, 우리 모두의 백과사전

https://www.youtube.com/watch?v=RP_f5dMoHFc&t=1064s 

https://www.youtube.com/watch?v=Nxi8Ur89Akw&t=109s 

https://www.inflearn.com/course/spring_rest-api/

스프링 기반 REST API 개발 - 인프런 | 강의