본문 바로가기

Development/Spring

REST API 특징 정리(https://restfulapi.net 참고)

API(Application Programming Interface)는 소프트웨어 간 데이터전송해 주는 인터페이스로서, 서버구조 프로세스에 대한 이해없는 클라이언트 사용자도 서버이용할 수 있도록 중개 역할을 해 준다. API는 관심사를 분류하는 리소스와 행위를 담당하는 HTTP method를 모두 포함하고 있다.

 

REST(REpresentational State Transfer) API REST 구조를 따르는 인터페이스화면의 출력구조를 포함하지 않고, 화면을 구현하는 데 사용될 데이터만 전달하는 API를 뜻한다.

 

이하의 내용은 https://restfulapi.net/ 의 내용을 참고(사실상 사용)하여 작성했다. 해석 과정에서 의역이 많이 들어갔기 때문에 원문과 많이 달라질 수 있다.

 

 

What is REST - REST API Tutorial

REST is an acronym for REpresentational State Transfer. It is an architectural style for hypermedia systems and was first presented by Roy Fielding.

restfulapi.net

 

 

일관된 인터페이스(Uniform Interface)

 

 

By applying the principle of generality to the components interface, we can simplify the overall system architecture and improve the visibility of interactions.

Multiple architectural constraints help in obtaining a uniform interface and guiding the behavior of components.

The following four constraints can achieve a uniform REST interface:

  • Identification of resources – The interface must uniquely identify each resource involved in the interaction between the client and the server.
  • Manipulation of resources through representations – The resources should have uniform representations in the server response. API consumers should use these representations to modify the resources state in the server.
  • Self-descriptive messages – Each resource representation should carry enough information to describe how to process the message. It should also provide information of the additional actions that the client can perform on the resource.
  • Hypermedia as the engine of application state – The client should have only the initial URI of the application. The client application should dynamically drive all other resources and interactions with the use of hyperlinks.

 

해석 : 컴포넌트(구성요소)의 인터페이스에 보편적인 원리를 적용함으로써, 전체 구조단순화하고 상호작용을 시각적으로 확인할 수 있다.

여러 구조적 제약을 통해 일관된 인터페이스를 가질 수 있으며, 컴포넌트의 행위를 지시할 수 있다.

아래의 네 가지 제약사항을 통해 일관된 REST 인터페이스를 설계할 수 있다.

 

리소스의 식별 - REST 인터페이스는 클라이언트와 서버의 상호작용에서 산출된 각 리소스고유방식으로 식별해야 한다.

 

리소스의 상태 표현을 통한 리소스 조작 - 리소스는 서버 응답 과정에서 일관된 형태표현 방식을 가지고 있어야 한다. API 이용자가 서버의 리소스 상태를 변경하려면 이러한 표현 방식을 사용해야 한다.

 

스스로에 대해 설명할 수 있는 메시지  - 진행과정을 설명하기 위해 각각의 상태 표현은 정보를 충분히 담고 있어야 하며, 클라이언트가 리소스에 취할 수 있는 추가 행위에 대한 정보를 제공해야 한다.

 

애플리케이션 상태 엔진으로서의 하이퍼미디어(상태를 표현하는 데이터 형식) - 클라이언트는 애플리케이션의 초기 URI만소유하고 있어야 한다. 클라이언트 애플리케이션은 하이퍼링크 사용을 통해 모든 리소스상호작용제어해야 한다.

 

 


 

 

REST 서버는 HTTP 표준 전송 규약을 따르므로, 개발 언어 또는 플랫폼, 기술의 제약을 받지 않고 높은 호환성을 바탕으로 이용이 가능하다.

 

REST API에서 모든 리소스는 독립적이고 고유한 인터페이스를 소유한다. 따라서 개별 웹 페이지의 변경은 전체 웹 브라우저에 영향을 미치지 않는다.

 

 

Client-Server 구조

 

 

The client-server design pattern enforces the separation of concerns, which helps the client and the server components evolve independently.

By separating the user interface concerns (client) from the data storage concerns (server), we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.

While the client and the server evolve, we have to make sure that the interface/contract between the client and the server does not break.

 

해석 : Client-Server 디자인 패턴은 관심사를 강제로 분리하여, 클라이언트서버의 컴포넌트가 독립적으로 역할을 수행하도록 한다.

UI(클라이언트의 관심사)를 데이터 저장(서버의 관심사)과 분리함으로써 여러 플랫폼에서의 UI 호환성이 개선되고, 서버의 구성요소를 단순화하여 확장이 용이해진다.

클라이언트와 서버가 각자 역할을 수행하는 동안 양자의 인터페이스 연결이 끊어지지 않도록 유의해야 한다.

 

 


 

 

REST API는 화면 구현에 관여하지 않고 데이터만을 전송하므로, 프론트엔드백엔드의 서로에 대한 의존성을 낮추고 각자관심사(UI 구현과 데이터 저장, 비즈니스 로직)에 집중할 수 있게 해 준다. 이를 통해 각자의 전문분야에서 효율적으로 개발을 진행할 수 있다.

 

 

무상태성(Statelessness)

 

 

Statelessness mandates that each request from the client to the server must contain all of the information necessary to understand and complete the request.

The server cannot take advantage of any previously stored context information on the server.

For this reason, the client application must entirely keep the session state.

 

해석 : 무상태성은 클라이언트가 전송하는 각각요청이 반드시 이해 가능해야 하고, 요청을 수행하기 위한 정보포함하고 있어야 하는 성질이다.

서버는 사전에 저장된 정보를 이용할 수 없으므로, 클라이언트 애플리케이션은 이전요청 상태를 완전하게 유지해야 한다.

 

 


 

 

무상태성(stateless)은 상태를 유지하는 stateful과 반대되는 개념으로, 서버가 클라이언트의 요청에 대한 세션이나 쿠키 정보를 별도로 보관하지 않고, 클라이언트가 매번 완전한 요청 정보를 담아 전송하는 방식이다. 

 

클라이언트가 전송해야 하는 데이터는 점차 증가하게 되지만, 요청 도중 서버변경되어도 완전한 요청을 받을 수 있기 때문에 서버는 이전의 요청 상태를 저장하지 않아도 된다. 따라서 클라이언트의 요청이 급증하더라도 여러 서버가 번갈아 가며 요청을 받을 수 있고, 이에 따라 서버의 확장성이 높아지게 된다. 또한 서버가 불필요한 정보를 관리하지 않으므로, 단순한 설계가 가능해지며 비즈니스 로직의 자유도가 높아진다.

 

다만 로그인 서비스 등 서버의 상태 저장이 필수적인 서비스에서는 사용할 수 없다.

 

 

캐싱 지원(Cacheable)

 

 

The cacheable constraint requires that a response should implicitly or explicitly label itself as cacheable or non-cacheable.

If the response is cacheable, the client application gets the right to reuse the response data later for equivalent requests and a specified period.

 

해석 : 캐싱을 위해서는 응답이 캐싱이 가능한 지 여부를 알 수 있어야 한다.

응답이 캐싱 가능한 경우 클라이언트의 애플리케이션은 이후에도 일정 기간 동안 동일 요청에 대해 응답 데이터재사용할 수 있는 권한을 가지게 된다.

 

 


 

 

REST는 HTTP 표준 전송 규약을 따르므로 HTTP캐싱 기능을 적용할 수 있다.

 

웹 애플리케이션에 요청할 때마다 매번 방대한 양의 응답 데이터를 전송받아 사용하는 방식은 비효율적이다. 로컬 컴퓨터에 저장된 캐시 데이터를 통해, 클라이언트는 한 번 이용한 웹 사이트를 다시 방문할 때 빠르고 편리하게 이용할 수 있다.

 

또한 서버의 트랜잭션 부하를 줄일 수 있어 효율적서버 운용이 가능해진다.

 

 

계층 구조(Layered System)

 

 

The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior.

For example, in a layered system, each component cannot see beyond the immediate layer they are interacting with.

 

해석 : 계층 구조 스타일을 통해 컴포넌트의 행위를 통제함으로써, 계층적 구조를 형성할 수 있다.

예를 들어 계층 구조에서 각 컴포넌트는 상호작용 대상의 계층 이상의 것을 알 수 없다.

 

 


 

 

서버의 각 계층은 데이터 전송용 객체인 DTO를 통해 데이터를 전달하므로, 타 계층의 관심사에 관여할 수 없다. 이를 통해 각 계층은 각자의 관심사에 온전히 집중할 수 있고, 보다 효율적으로 프로세스를 처리할 수 있다. 이와 마찬가지로 REST 네트워크 서버는 여러 계층으로 구성되어 계층 간 효율적인 분업을 촉진시킨다.

 

 

맞춤형 코드 (선택사항)

 

 

REST also allows client functionality to extend by downloading and executing code in the form of applets or scripts.

The downloaded code simplifies clients by reducing the number of features required to be pre-implemented. Servers can provide part of features delivered to the client in the form of code, and the client only needs to execute the code.

 

해석 : REST는 클라이언트가 직접 다운로드 받아 실행할 수 있는 applet이나 script 형태의 코드를 제공하며, 이를 통해 기능을 확장할 수 있다.

해당 코드를 통해 사전에 구현해야 할 기능을 줄임으로써 클라이언트 단순화할 수 있다. 서버는 이 코드에 포함된 일부 기능을 제공할 수 있으며, 클라이언트는 코드실행하기만 하면 된다.

 

 


 

 

클라이언트와 서버 영역 간 철저한 분리에 따른 불편함을 완화하기 위한 수단으로 보인다. 맞춤형 코드를 통해 클라이언트는 서버에 대한 복잡하고 번거로운 이해 과정을 줄이고, 최소한이해도를 토대로 편리하게 이용할 수 있다. 따라서 본연관심사집중할 수 있게 된다.