[REST API] REST API인가? Web API인가?

API? (Application Programming Interface)

---

API는 번역하면 응용 프로그램 인터페이스로

응용 프로그램에서 사용할 수 있도록 OS나 프로그래밍 언어가 제공하는 기능들을 제어할 수 있게 만든 Interface입니다.

어떤 목적을 위해서 정보나 기능을 다른 사람들이 사용하기 쉽게 모듈화해서 제공합니다. 우리는 해당 API를 사용해서 그 기능을 추가한 프로그램을 개발할 수 있습니다. 

우리가 자바에서 절대 값을 구하고 싶을 때, Java언어가 제공하는 Math클래스의 abs()메소드 사용. 절대값 구하는 코드를 몰라도 해당 인터페이스만 알면 사용 가능합니다.  

ex) 카카오맵 api를 사용해 맛집지도 애플리케이션, SandBird Chat API를 활용한 협업도구 개발 등등

REST API(REpresentational State Transfer API) 

---

클라이언트가 Web Application / Android Application / iOS Application / React Native 등 다양해지고 이런 클라이언트들에게 정보를 제공하는 방법을 하나로 정하고 싶었습니다(일원화)

 그 방법 중 많이 통신하는 방법이 HTTP 프로토콜을 통해서 API를 제공하는 것입니다. 이런 HTTP 프로토콜을 통해서 제공하는 API가 REST API입니다.

즉, REST API는 "웹 애플리케이션이 제공하는 각각의 데이터를 자원(Resource)으로 간주하고 각각의 자원에 고유한 URI(Uniform Resource Identifier)를 부여해 이를 API를 정의하기 위한 소프트웨어 아키텍처 스타일이다" 라고 할 수 있습니다. 특이점은, HTTP 메소드를 이용해 각각의 자원에 CRUD 작업을 한다는 점입니다!

■ REST 아키텍쳐

REST는 Representational State Transfer이라는 용어의 약자로 2000년도에 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다.  로이 필딩은 HTTP의 주요 저자로, 그 당시 웹이 HTTP의 설계의 우수성에 비해서 제대로 활용되지 못하는 걸 안타까워하며 웹의 장점을 최대한 활용하는아키텍쳐로써 이 REST를 발표했습니다.

■ REST 구성

Resource : REST의 가장 중요한 요소 중 하나로 말 그대로 시스템의 자원입니다. (HTTP의 URI로 표현)

ex) 영화예매 시스템의 사용자, 예약번호, 좌석번호, 영화정보 등이 시스템의 resource라 할 수 있습니다. 

Verb : Resource의 행위를 정의합니다. (HTTP Method로 표현) - GET(조회)/ POST(생성)/ PUT(갱신)/ DELETE(삭제)를 통해서 CRUD를 실행

Representations : Resource 행위에 대한 내용을 정의합니다. (HTTP Message Pay Load로 표현)

즉, REST는 URI를 통해서 Resource에 접근하고 / Resource에 어떠한 행위(CRUD)를 할 지 HTTP 메서드로 나타내는 방법이라고 할 수 있습니다.

보통은 //{ 리소스 그룹명} / {리소스 ID}로 표현합니다.

ex) mybestmovie.net/reviews/1/posts/jin

mybestmovie.net 서버의 리뷰들중 첫 번째 게시판의 글들 중 jin의 글이다! 이런 식으로 표현합니다. 

이렇게 REST 아키텍쳐는 해당 URI만 보고도 어떤 Resource인지 쉽게 파악이 가능합니다.

■ REST API 

REST API는 핵심 Contents 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 Interface입니다.

ex) 네이버 블로그에서 글을 저장하고, 글 목록을 읽어가도록 외부에 기능을 제공하거나, 구글에서 구글 지도를 사용하도록 제공 등등

REST API는 웹의 장점을 최대한으로 사용하기 위해서 고안되었지만, 현재 웹 브라우저 외에도 모바일 애플리케이션 등 다양한 클라이언트에 대응하기 위해서 REST API가 엄청나게 사용되기 시작했습니다. 이를 매시업(MashUp)이라고 합니다.

로이필딩 왈: 이것은 REST가 아니야!

이렇게 REST가 엄청나게 퍼지고 많이 사용됬지만 로디필딩은 대부분 REST API라 하는 것들이 REST API가 아니라고 말하면서 

REST는 반드시 다음과 같은 스타일을 갖춰야 한다고 말합니다.

1) Client - Server (클라이언트와 서버 구조)

:  REST 서버는 API를 제공, 클라이언트는 session, 정보들을 직접 관리하는 구조로 서버와 클라이언트의 개발 영역이 명확하게 나뉘고, 서로 의존성이 떨어지게 됩니다. (Front-End / Back-End의 역할이 분명해짐)

2) Stateless (무상태성)

: REST는 상태 정보를 따로 저장,관리하지 않습니다(Stateless). 세션이나 쿠키 정보를 별도로 저장,관리하지 않으므로 API서버는 들어오는 requset만 단순 처리하면 됩니다. 따라서, 서비스 자유도가 높아지고 서버에 불필요한 정보를 관리하지 않으므로 구현이 간결해집니다. 

3) Cache (캐시 가능)

: REST의 가장 큰! 특징은 HTTP라는 기존의 웹 표준을 그대로 따른다는 것입니다. 이 말은 곧, 기존의 웹 자원들을 그대로 활용할 수 있다는 점입니다. 따라서 HTTP가 가진 캐싱(임시 저장) 기능이 적용가능합니다.

[참고] https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=ko

4) Uniform Interface(유니폼 인터페이스)

: 유니폼 인터페이스는 URI로 지정한 Resource(자원)에 대한 조작을 통일하고 한정적인 인터페이스로 수행하는 아키텍터 스타일

5) Layered System

: REST 서버는 다중 계층으로 구성될 수 있습니다.

6) Self-descriptiveness (자체 표현 구조)

: REST는 또한 REST API 내용만 보고도 별도 문서 없이 쉽게 이해할 수 있습니다.

위의 조건들을 만족해야만 REST다! 라고 할 수 있습니다. HTTP프로토콜을 이용하면 위의 조건을 쉽게 구현할 수 있는데, 한 가지 조건이 걸립니다.

바로 Uniform Interface입니다.

Uniform Interface 스타일 특징

1. 리소스가 URI로 식별되야 합니다.
2. 리소스를 생성/수정/추가하고자 할 때 HTTP메시지에 표현해서 전송해야 합니다.
3. 메시지는 스스로 설명할 수 있어야 합니다.(self - descriptive message)
4. 애플리케이션의 상태는 하이퍼링크를 통해서 전이되어야 합니다. (HATEOAS)

1,2번 항목은 지키기 어렵지 않은데, 3,4번 항목은 Web과는 다르게 API로 쉽지 않습니다.

요청에 대한 응답 결과로 보통 JSON포맷을 많으 사용하곤 합니다. 그런데 이 JSON메시지가 어디에 전달되는지 그리고 JSON메시지를 구성하는 것이 어떤 의미를 표현해야 메시지 스스로 설멍할 수 있다고 할 수 있는데, 그게 쉽지 않습니다. 그리고 HATEOAS를 API에서 제공하는 것도 상당히 어렵습니다.

REST API는 쉽지 않다!! 그래서, 보통 Web API(혹은 HTTP API)를 사용합니다.

REST에서 Uniform Interface를 지원하는게 쉽지 때문에, 많은 서비스에서 REST에서 요구하는 모든 걸 충족시키지 않고 API를 만들게 됩니다.

사람들이 REST API라고 하지만, REST API가 아닌경우.

- REST의 모든 것을 제공하지 않고, REST API라고 부르는 경우 

- REST의 모든 것을 제공하지 않고, Web API 혹은 HTTP API라 부르는 경우

우리는 2번째 방식을 따라 Web API, HTTP API로 불러야합니다. 혹여나 프로젝트 설계 부분에서 REST API로 구현하기로 했는데 Uniform Interface 스타일을 따르지 않고 REST API야! 라고 우길 경우 설계단부터 다시 할 큰 피해를 초래할 수 있습니다, (협업시 용어 의미를 명확히 짚고 가야하는 이유!)

HATEOAS( Hypermedia As The Engine Of Application State )

마틴 파울러님이 RESTful을 향하는 3단계 

[원본] https://martinfowler.com/articles/richardsonMaturityModel.html

Level1 : 리소스 도입

서버가 가진 모든 데이터를 하나의 Resource로 관리해 고유한 URI를 제공함으로써 클라이언트가 단인 API 엔드포인트가 아니라 각 리소스와 직접 데이터 통신을 합니다.

Level2 : HTTP 동사 

HTTP 동사를 활용해 리소스에 대한 수행할 작업 종류를 표현합니다.

Level3 : 하이퍼미디어 조작

HATEOAS를 통해 리소스에 대하여 호출 가능한 API에 대한 정보를 리소스 상태를 반영해 표현합니다.

HATEOAS는 HTML Link 개념으로 다른 리소스와 관련 있는 것들에 대한 링크를 제공함으로써 자기표현(self-descriptiveness)을 더 분명하게 나타냅니다. 좋은 점이 많긴하지만, 의존성이 높아져 업데이트 하기가 어려워집니다.

전형적인 REST API 응답 데이터

{
"reservedMovie" : "Avengers : End Game",
"Date" : 20190422,
"numbers" : 2,
"seats" : ["J33","J34"]
}

HATEAOS가 도입되어 리소스의 추가 정보가 링크로 제공되는 응답 데이터

{
"reservedMovie" : "Avengers : End Game",
"Date" : 20190422,
"numbers" : 2,
"seats" : ["J33","J34"]
"links": [
{
"rel": "event"
"href": "http://megabox.com/users/event"
},
{
"rel": "review"
"href": "http://megabox.com/users/review"
}
]
}

[참고]

https://www.slideshare.net/Byungwook/rest-api-60505484 (조대협님 REST API 설계 자료)

https://blog.naver.com/PostView.nhn?blogId=tmondev&logNo=220391644590&proxyReferer=https%3A%2F%2Fwww.google.com%2F (Hypermedia-driven REST API 티몬 기술블로그)

https://meetup.toast.com/posts/92

[ edwith - 웹프로그래밍 부스트코스 ] 를 개인적으로 공부하고 정리한 공간입니다. 잘못된 부분은 피드백 주시면 감사하겠습니다