[바미] REST API에 대하여

안녕하세요. 오늘은 REST API에 대해 알아보고자 합니다.

---

REST?

흔히  개발을 하셨던 분들이라면 'REST하다.' 라는 표현을 접해보셨을 겁니다. 개발하면서 흔히 접했지만 정확히 얘기하지 못하는 부분 중 하나가 REST-API가 아닌가 싶습니다.

REST(Representational State Transfer)의 사전적인 의미들을 요약해보면 'REST라는 아키텍쳐 스타일을 따르는 API'라고 표현 할 수 있습니다.

 

그러니까 HTTP를 기반으로, 자원을 정의하고, 자원에 접근하는 방식을 정해 놓은 아키텍쳐인데 웹에 존재하는 모든 자원에 고유한 식별자인 URI을 부여해 활용합니다.

여기서 자원은 저장된 데이터(DBMS), 이미지, 동영상, 문서 파일, 서비스 (이메일, 메시지)를 모두 포함합니다.

흔히 말하는 CURD 즉, 생성(POST), 수정(PUT), 조회(GET), 삭제(DELETE)를 통해 접근하죠.

 

참고로 REST를 프로토콜이나 표준으로 오해하면 안됩니다.

---

위에 설명했듯이 REST API는 REST라는 아키텍쳐 스타일을 따르는API라고 했습니다. 여기에 적용되는 제약 조건 몇 가지가 있습니다.

 

Client - Server

• 클라이언트와 서버가 각각 독립적으로 분리되어 있다.

Stateless

• 클라이언트의 상태가 서버가 저장하지 않는다.

Cacheable

• 클라이언트는 응답을 캐싱 할 수 있다.

Layered system

• API 서버는 순수 비지니스 로직을 수행 한다.
• 클라이언트는 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지 인지 할 수 없다.
• 중간 서버 (로드 밸런싱, 공유 캐시)를 제공함으로써 시스템 규모 확장성이 향상 된다.

Uniform interface

• 리소스는 URI로 식별 된다.
• HTTP 메시지를 통해 리소스를 조작 할 수 있다.
• Self-descriptive messages (자기 서술적 메시지)
• hypermedia as the engine of application state (HATEOAS)

Code on demand (optional)

• 서버가 클라이언트에게 코드를 응답해주면, 클라이언트는 응답 코드를 실행 할 수 있다
  ex) Javascript

이것이 REST의 제약 조건들입니다. 오늘 날의 REST API라고 불리는 API들은 모두 REST의 아키텍쳐 스타일을 만족할까요? 대부분은 HTTP의 특징이기도 하며, HTTP만 잘 따르더라도 대부분 잘 지킬 수 있지만

Uniform interface의 Self-descriptive messages나 HATEOAS를 만족하는 API는 찾기 힘들다고 합니다.

---

그렇다면 왜 REST API의 개념이 나오게 되었나?

요약하자면 '애플리케이션 분리 및 통합', '다양한 클라이언트의 등장' 때문입니다.

애플리케이션의 복잡도가 증가하면서 애플리케이션을 어떻게 분리하고 통합하느냐가 주요 이슈가 되었고, 이에 자바 진영에서는

과거 EJB(Enterprise Java Beans), SOA(Service Oriented Architecture)에 이어 최근에는 MSA(Micro Service Architecture)와 함께 REST가 떠오르고 있는 것이죠.

 

게다가 모바일과 같은 다양한 클라이언트의 등장하면서 Backend 하나로 다양한 Device를 대응하기 위해 REST의 필요성이 증대되었습니다.

---

REST API 구성

REST API는 자원(Resource), 행위(Verb), 표현(Representations)의 3가지 요소로 구성됩니다.

REST는 자체 표현 구조로 구성되어 REST API만으로 HTTP 요청(Request)의 내용을 이해할 수 있습니다.

Todo 기능을 구현한다고 가정했을 때의 Restful API 표준

Endpoint	기능
GET /todos	List all todos
POST /todos	Create a new todo
GET /todos/:id	Get a todo
PUT /todos/:id	Update a todo
DELETE /todos/:id	Delete a todo and its items
GET /todos/:id/items	Get a todo item
PUT /todos/:id/items	Update a todo item
DELETE /todos/:id/items	Delete a todo item

---

REST API의 장단점

장점

1. Easy to use (쉬운 사용)

REST API의 가장 큰 장점이라고 할 수 있습니다. 단순히 REST API 메시지를 읽는 것 만으로도 메시지가 의도하는 바를 명확하게 파악할 수 있죠. 굳이 해당 메시지의 기능이 무엇인지 알기 위해 메뉴얼을 하나씩 읽어 볼 필요가 없게 만들어 줍니다. 정리하면 엄청난 가독성이죠.

또한 HTTP 인프라를 그대로 사용하기 때문에, REST API 사용을 위한 별도의 인프라 구축을 요구하지 않습니다. 그리고 Stateless한 특징 때문에 수행 문맥(Execution Context)가 독립적으로 진행됨으로써 이전에 서버(호스트)에서 진행된 내용들에 대해 클라이언트가 알 필요가 없으며, 이제까지 진행된 히스토리에 대해서도 알 필요가 없게 됩니다. 즉 해당 URI와 원하는 메소드 자체만 독립적으로 이해하면 되죠.

2. 클라이언트와 서버의 완전한 분리

클라이언트는 REST API를 이용하여 서버와 정보를 주고 받습니다. 위에서 언급한 Stateless 한 특징에 따라, 서버는 클라이언트의 문맥을 유지할 필요가 없게 됩니다.

 

결국 클라이언트와 서버는 ‘니들 일은 니들이 알아서 해’ 식으로 동작하게 됩니다. 서로에게 무관심한 이기적인 상황이라고 느껴지시나요? 하지만 실제로는 각자의 역할이 명확하게 분리되어 있다는 의미로 보는게 더 맞습니다. 

 

이러한 장점은 단순히 업무량 감소를 넘어 플랫폼의 독립성 확장이라는 효과를 가져올 수도 있는데요, HTTP 프로토콜 서비스라는 기본적인 요구만 충족되면 다양한 플랫폼에서 원하는 서비스를 쉽고 빠르게 개발하고 배포할 수 있게 됩니다. 

리눅스 웹 서버에서 윈도우 플랫폼 기반의 웹 브라우저를 순식간에 동작시킬 수 있다는 말이죠.

3.  특정 데이터 유형에 대한 세부 표현식

REST API는 헤더 부분에 URI 처리 메소드를 명시함으로써, 필요한 실제 데이터를 페이로드(바디)에 표현할 수 있도록 구성할 수 있는 기능을 제공합니다. 이는 특정 메소드의 세부적인 표현 문구를 JSON, XML 등 다양한 언어를 이용하여 작성할 수 있다는 장점 뿐만 아니라, 간결한 헤더 표현을 통한 가독성 향상이라는 두마리 토끼를 잡는 효과를 가져다 주게 되죠. 

단점

1.  HTTP 방식의 제한

REST API는 HTTP 메소드를 사용하여 URI를 표현합니다. 이러한 표현 방법은 다양한 인프라에서도 편리하게 사용할 수 있다는 장점을 주지만, 또 한편으로는 메소드 형태가 제한적 이라는 문제점을 가져오기도 합니다.

 

물론 내부 Context를 이용할 수 있습니다. 하지만 이 방법이 모든 부분에서 해결책을 제공하지는 못합니다. 예를 들어, 메일을 보내는 기능을 작성한다고 합시다. 단순히 보내는 기능 외에도 누구한테, 얼마나 많이, 시간을 예약해서 등 다양한 세부 기능들 또한 작성해야하는데, 이러한 여러 기능들을 구현하는데 제약이 발생할 수 있겠죠.

2. 표준의 부재

REST API의 가장 큰 단점이라고 할 수 있는데, 바로 표준이 존재하지 않습니다. (다르게 표현하면 입김 센 놈이 장 땡) 이는 관리의 어려움과 좋은(공식화 된) API 디자인 가이드가 존재하지 않음을 의미하는데요, 결국 REST API는 많은 사람들이 하나씩 쌓아올리는 ‘정당화 된 약속들’ 로 구성되고 움직이게 됩니다. 

 

이 부분에 대해 어떤 사람들은 ‘확장성과 발전 가능성’을 이야기합니다만, 표준의 유무는 기대감과 별도로 매우 중요한 요소입니다. 국내에도 이런 광고가 있었죠, ‘모두가 YES라고 할 때, NO라고 할 수 있는 사람’. 누군가에게는 표준의 중요성이 절실할 수 있습니다.

---

이상으로 REST-API에 대해 알아보았습니다.

틀린부분이 있다면 알려주세요!

참조

https://www.slipp.net/wiki/pages/viewpage.action?pageId=12878219
http://mygumi.tistory.com/55
https://brainbackdoor.tistory.com/53
http://tech.devgear.co.kr/delphi_news/433404
https://meetup.toast.com/posts/92
https://spoqa.github.io/2012/02/27/rest-introduction.html
https://hackernoon.com/build-restful-api-in-go-and-mongodb-5e7f2ec4be94
https://docs.oracle.com/cd/E76467_01/alloc/pdf/141/html/operations_guide/alloc-og_restful-impl.htm
SOAP과 REST의 차이
https://wallees.wordpress.com/2018/04/19/rest-api-%EC%9E%A5%EB%8B%A8%EC%A0%90/