[HTTP] API 그리고 REST API

API:

Application Programming Interface

 

API

API라는 것은 결국

클라이언트(사용자)와 프로그램, 프로그램과 프로그램 간의

요청 응답을 하게 해주는 "모든" 것이다

(내가 이해 한 바로는)

 

예를 들어 날씨 정보를 조회하는 API를 만든다고 하자

API 예시

날씨는 시간, 지역마다 다르기 때문에 이러한 정보들이 분명 필요할 것이다

그래서 클라이언트에게 이에 해당하는 정보를 받아 프로그램(서버)으로 넘겨준다

 

 여기에 한번 더 들어가 보자

서버에서 요청을 받았는데 클라이언트가 원하는 것은

한국의 날씨 정보가 아니라 미국의 날씨 정보였다

 

그래서 미국 자료를 줄 수 있는 프로그램에게 요청을 한다

API예시

이렇듯 API는 클라이언트는 물론 서버 간의 요청과 응답도 가능하게 한다

 

구글, 다음카카오, 네이버 등도 자신들의 오픈 API를 제공하는데

이들이 제공하는 것은 대부분 REST API이다.

 

REST

사실 REST API는 그것 자체로 독립된 개념이 아니라

"API" 를 "REST" 하게 만드는 것이 REST API이다

 

Representational State Trasfer의 약자인 REST는

리소스를(이미지, 동영상, DB자원 등의) 구분하여 해당 리소스의 상태를 주고받는 모든 것을 의미한다

REST~

그렇다면 REST를 구성하는 개념들은 무엇일까

아래와 같다

 

1.Resource(자원의 식별)

요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.

-> 위에서 예를 든 URI의 개념 같은 것이다, 회원이라는 자원(리소스)이 서버가 받게 되는 데이터를 분리해야 한다는 것이다, 이를 JSON 같은 행태로 전송하여 서버가 자원과 데이터를 각기 다르게 인식할 수 있어야 한다는 것이다

 

2.Verb(메시지를 통한 리소스의 조작)

클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.

-> HTTP 메시지를 통한 리소스의 조작인데, 이것은 간단하게 말하면 HTTP의 메서드로 위의 예시처럼 POST는 등록 / GET은 조회 같이 리소스를 변경이나 삭제 그리고 조회할 수 있게끔 해야 한다는 것이다

 

3.Representations(자기 서술적 메시지)

각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다.

-> HTTP에는 다양한 문서 양식(인코딩)이 있다, 예를 들어 단순한 text라면 text/plain, JSON이라면 application/json 이렇게 다양한 양식들을 구분하여 서버에게 정확히 알려주어야 한다는 것이다.

 

4.HATEOAS(애플리케이션의 상태에 대한 엔진으로써 하이퍼 미디어)

만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.

-> 애플리케이션의 상태가 하이퍼미디어에 의해 변경되는 것, 즉 유튜브 메인화면에서 내가 보고자 하는 영상들은 각자의 링크를 가지고 있을 것이다, 이 링크를 통해서 클라이언트는 서버에게 이 애플리케이션의 상태를 변경할 수 있게끔 요청할 수가 있다, 이것이 바로 HATEOAS다

 

이렇게 REST 한 API를 만드는 이유는 무엇일까?

아래의 특징에서 답을 찾아보자

 

1. Client-ServerI(서버-클라이언트 구조)

-> 단순하게 클라이언트와 서버의 역할을 구분하는 것이다. 이를 구분하는 것은 리소스의 유무인데, 리소스를 요청하는 쪽이 Client, 리소스를 가지고 있는 쪽이 Server가 된다, REST Server로 예를 들면 API를 제공하며 비즈니스 로직에 의한 처리와 저장을 책임진다, 클라이언트 같은 경우는 사용자 인증이나 세션 같은 정보들을 직접 관리하고 책임지게 된다, 이로써 서로 간의 의존성이 줄어든다.

 

2. Stateless(무상태)

-> HTTP 프로토콜은 기본적으로 Stateless 즉 무 상태이기 때문에 REST 역시 무상태성을 갖는다. 쉽게 말해서 State, 상태를 가지고 있느냐 없느냐인데, 클라이언트가 가지고 있는 세션과 같은 정보는(가지고 있는 상태) 서버 쪽에서 신경 쓸 필요가 없기 때문에 요청하는 비즈니스 로직만 신경 쓰면 된다는 것이다. 그리고 이러한 요청들은 다음 요청의 처리와 연관되지 않아야 한다. 이는 서버에게 일관적인 처리 방식을 처리하게 해 주기 때문에 서버 쪽의 부담이 줄어들고 클라이언트가 누리는 서비스의 자유도도 높아진다

 

3.Cacheable(캐시 처리 가능)

-> 위의 구성중 자기 서술적 메시지 덕분에 각각의 요청은 그 자체로 해석이 가능하다, 이로써 독립적인 처리가 가능하게 되었는데 그 결과 Caching이 가능해졌다, 즉 HTTP의 캐시 기능을 사용할 수 있다는 것이다. 예를 들어 Last-Modified 태그나 E-Tag를 통한 캐싱도 가능한 것이다 그러므로 대부분 서비스 시스템의 조회성 트랜잭션이 유발하는 비효율적인 구조를 캐시를 사용함으로써 대량의 요청도 효율적으로 처리할 수 있는 것이다.

 

4.Layered System(계층화)

-> 말 그대로인데, 아파트(서버라고 가정하고)를 떠올려보자 예를 들어 클라이언트가 엘리베이터를 타는데, 이 엘리베이터가 바로 REST API Server의 호출이다. 이렇게 엘레베이터에 타고 나면 (호출하고 나면) 엘레베이터가 올라가며 층층이 보안, 로드밸런싱, 암호화, 사용자 인증 등을 통과하며 클라이언트가 가고 싶어 하는 층까지 데려다준다. 이런 식으로 비즈니스 로직의 계층화는 구조상 유연상을 둘 수 있는데 쉽게 말해서 엘리베이터를 타고 가는 중에 한 가지의 인증을 더 추가하려면 그 사이에 끼워넣기만 하면 되는 것이다

 

5.Uniform Interface(인터페이스 일관성)

-> HTTP의 표준만 따른다면 모든 플랫폼에서 사용이 가능하다, 즉 특정 언어나 기술에 종속되지 않는 것이다.

 

이렇게 REST 기반으로 API를 만듦으로써 확장성과 재사용성을 효율적으로 높이고

유지보수와 운용의 편리함을 증대할 수 있다.

 

REST API

좋은 REST API를 만들기 위해서는 URI 디자인 가이드가 있는데

가장 중요한 것은 2가지로 요약할 수 있다.

 

1.URI는 정보의 리소스를 표현해야 한다

test.com/members

회원에 대한 CRUD를 구현한다면 members라는 리소스를 꼭 표현해야 한다는 것이다

 

2. 리소스에 대한 행위를 표현해야 한다

행위를 표현해야 하나 이를 URI에 담아서는 안된다

POST / GET / PUT / DELETE와 같은 HTTP 메서드로 구분하여 표현해야 한다

 

URI를 만들 때도 주의할 점이 있는데 그중 중요하다고 하는 것들 몇 가지를 살펴보자

URI 작성 시 유의

 

RESTful

REST라는 아키텍처를 구현하는 서비스를 나타내는 용어인데

예를 들어 REST API를 제공하는 웹서비스를 "RESTful"하다고 얘기할 수 있겠다

 

이는 REST API와 같이 독립적인 개념이 아니라

REST 하게 쓰는 것을 목적으로 한, 그리고 REST의 원리를 따르는 시스템 또는 서비스를 RESTful이란 용어로 지칭하는 것이다

 

만약 CRUD의 기능을 모두 POST로 처리한다던지

GET을 조회 이외의 다양한 용도로 사용한다던지

URI에 리소스 외의 정보가 들어간다던지 한다면

이는 "RESTful" 하지 않다고 할 수 있겠다.

 

허나 이는 이상적인 개념일 뿐이고, 만약 RESTful을 지키는 것보다 좀 더 효율적이고

합리적인 대안이 있다면 그것을 따르는 것도 무방하다고 한다.

 

---

개인 학습을 위해 작성되는 글입니다.

제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.

 

참조 링크:

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

https://ibks-platform.tistory.com/287

https://junho94.tistory.com/31

https://engkimbs.tistory.com/866