24DAY 백엔드 - 13DAY API에 대해서 배우기

 

1. REST

이제는 전통적인 JSP 웹 애플리케이션이나 ASP.NET 애플리케이션처럼 하나의 프로젝트로 전체 애플리케이션을 구현하는 설계보다는 클라이언트와 서버간의 역활 분리 및 서버 애플리케이션의 안정성과 확장성, 그리고 고가용성을 고려한 부산 애플리케이션/API 서버의 구현이 더욱 일반적이 되어가고 있습니다.

 

이러한 현상은 REST API의 등장 이후 더욱 뚜렷해 집니다.

REST API는 Representational State Transfer API의 약자로, 간단히 설명하면 "웹 애플리케이션이 제공하는 각각의 데이터를 리소스, 즉 자원으로 간주하고 각각의 자원에 고유한 URI를 할당함으로써 이를 표현하는 API를 정의하기 위한 소프트웨어 아키텍처 스타일입니다.

 

특이한 점은 해당 자원에 대한 기본적인 CURD 작업을 HTTP 동사(POST, GET,PUT, DELETE)를 이용해 처리한다는 점입니다. 

 

REST 구현의 3단계

REST 구현의 3단계

1. 리소스의 도입

서버가 가진 모든 데이터를 하나의 자원으로 관리하며 고유한 URI를 제공함으로써 클라이언트가 하나의 단일 API ㅏ엔드포인트가 아닌 각 자원과 직접 커뮤니케이션할 수 있도록 합니다.

 

2. HTTP 동사

HTTP 동사를 이용하여 자원에 대해 수행하고자 하는 작업의 종류를 표현합니다.

 

3. 하이퍼미디어 컨트롤

HATEOAS라는 개념을 통해 해당 자원에 대해 호출 가능한 API에 대한 정보를 자원의 상태를 반영하여 표현합니다.

 

Hypermedia-driven API

REST 구현의 세 번째 단계에서 다음 주제인 HATEOAS란 Hypermedia As The Engine Of Application State의 약자로, 기본적인 아이디어는 하이퍼미디어를 애플리케이션의 상태를 관리하기 위한 매커니즘으로 사용한다는 것입니다.

 

기본 REST API의 단점 

1. 일단 API의 엔드포인트 URL이 정해지고 나면 이를 변경 할 수가 어렵다는 점입니다.

• API의 URL을 변경하면 이를 사용하는 모든 클라이언트가 함께 수정되어야 하기 때문에 API URL에 버전을 적용하거나 해서 기존의 것과는 다른 API를 지속적으로 추가해 나가야 했고, 이로 인해 API URL의 관리에 어려움을 겪게 됩니다.

 

2. 기본적으로 REST API 자원의 상태를 고려라지 않는 디자인을 적용하고 있습니다

• 해당 자원에 대해 특정 작업을 수행하기에 앞서 필요한 데이터를 수집하거나 해당 작업이 가능한지 여부를 판단하는 로직 역시 모두 클라이언트가 가져야 합니다.

 

2. HATEOAS

HATEOAS(Hypermedia as the Engine of Application State)

다른 네트워크 애플리케이션 아키텍처와 구별 되는 REST 애플리케이션 아키텍처 의 구성 요소입니다 .

 

HATEOAS를 통해 클라이언트는 애플리케이션 서버가 하이퍼 미디어를 통해 동적으로 정보를 제공하는 네트워크 애플리케이션과 상호 작용합니다 . REST 클라이언트는 하이퍼 미디어에 대한 일반적인 이해를 넘어서 애플리케이션 또는 서버와 상호 작용하는 방법에 대한 사전 지식이 거의 필요하지 않습니다.

• HATEOAS는 REST API와 연관이 있다고 합니다.

HATEOAS를 통해 REST 3단계를 구현하는 경우 이런 단점을 어느 정도 해소할 수 있습니다. 그렇다면 HATEOAS를 도입한 경우의 API 응답은 지금까지의 REST API의 응답과는 어떤 차이점이 있는 걸까요? 아래 두 코드를 살펴보겠습니다.

 

예제 코드 1: 전형적인 REST API의 응답 데이터

예제 코드 2: HATEAOS가 도입되어 자원에 대한 추가 정보가 제공되는 응답 데이터

 

 

위의 두 코드에서 보듯이 HATEOAS를 통해 표현된 데이터에는 해당 자원의 상태에 따라 접근 가능한 추가 API들이 links 라는 이름으로 제공됩니다. 예제의 경우 해당 계좌에는 현재 350,000원의 잔액이 존재하므로 인출(Withdraw)및 송금(Transfer)을 실행할 수 있는 API의 엔드포인트들이 제공되며 rel 키워드에 의해 각 엔드포인트에 대한 유일한 이름이 할당됩니다. 따라서 클라이언트는 이 rel 이름만 알면 해당 기능의 실행 가능 여부 및 이를 실행하기 위해 필요한 데이터 역시 손쉽게 판단할 수 있게 됩니다. 또한 API 개발자들은 최초 진입을 위한 API 엔드포인트를 제외한 나머지 URL들을 얼마든지 수정할 수 있습니다.

 

마치며

HATEOAS는 REST API 구현의 3단계 중 가장 마지막 단계에 해당하는 부분입니다. 반드시 구현해야 할 필요가 있는 것은 아니지만 현재 애플리케이션이 REST API를 제공하고 있고 애플리케이션이 계속 성장하면서 늘어만 가는 REST API들의 관리에 어려움을 겪고 있다면 한 번쯤 도입을 고려해볼 필요는 있을 것입니다.

  

 

 

2. 오픈 API 스펙과 swagger

Open api: 누구나 사용할 수 있도록 공개된 API를 말하며, 개발자에게 사유 응용 소프트웨어나 웹 서비스에 프로그래밍적인 권한을 제공한다.

 

OpenAPI에서 빼놓을 수 없는 기능이 바로 Swagger 입니다.

 

Swagger는 위에서 생성된 api-docs를 기반으로 api를 HTML 문서화 해줍니다.

Swagger는 OpenAPI스펙을 맞춘 api-docs를 이용하여 HTML 페이지를 만들어주는 오픈소스 프레임워크로,RESTful API의 설계 및 문서화에 매우 도움을 줍니다.

 

 

 

4. JSON API

JSON : Douglas Crockford가 널리 퍼뜨린 javascript 객체 문법을 따르는 문자 기반의 데이터 포맷입니다. 

 

JSON은 문자열 형태로 존재합니다. 네트워크를 통해 전송할 때 아주 유용합니다. 데이터에 억세스하기 위해서는 네이티브 JSON 개개체로 변환될 필요가 있습니다.

 

 

 

5 SOAP

일반적으로 널리 알려진 HTTP,HTTPS,SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서교환하는 프로토콜입니다. 웹 서비스에서 기본적인 메시지를 전달하는 기반이 됩니다. 몇가지 형태의 메시지 패턴이 있지만 보통의 경우 원격프로시져 호출 패턴으로 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)로 메시지를 요청하고 ,서버는 메시지를 즉시 응답하게 됩니다. XML-RPC와 WDDX에서 envelpe/header/body로 이루어진 구조와 전송과 상호 중립성의 개념을가져왔습니다. XML을 근간으로 헤더와 바디를 조합하는 디자인 패턴으로 설계되어 있습니다.