RESTful API

API를 설계한다고 하면 대부분 RESTful API를 떠올리게 됩니다. 간결하고 직관적인 설계 때문에 굉장히 많이 사용되고 있는 API 방식입니다. 하지만 우리는 그저 "다른 사람들이 다 하니까" RESTful API 방식을 채택하고 있지는 않은지 생각해 볼 필요가 있다고 생각합니다. 따라서 이 포스트에서는 RESTful API가 무엇이며, 왜 널리 대중적으로 사용되고 있는지 알아보고 다음 포스트에서는 다른 방식은 어떤 것들이 있는지 살펴보고, 무지성으로 RESTful API를 사용하는것이 아닌 어떤 서비스에 어떤 방식이 적절할지 고민해보도록 하겠습니다.

 

REST API, RESTful API를 보통 혼용해서 사용하며 두가지 모두 REST 원칙을 준수하는 API로 의미는 같습니다. REST API를 알아보기 전에 우선 REST가 무엇인지 부터 알아보도록 하겠습니다.

 

# REST의 등장 배경

웹이 발전함에 따라 웹 서비스를 위한 표준화된 방법과 규칙이 필요해졌습니다. 초기에는 웹에서 제공하는 데이터에 접근하기 위해 웹 페이지를 스크래핑하는 방법 등이 사용되었지만, 이는 비효율적이고 유지보수가 어려웠습니다.

로이 필딩은 웹의 구조와 기본 원칙을 활용하여 웹 서비스를 개발하기 위한 아키텍처 스타일인 REST를 제안했습니다. 

 

 

# REST란?

Representational State Transfer의 약자로 자원(resource)을 이름(representation)으로 구분하여 해당 자원의 상태(state)를 전달 하는 방식을 사용하는 소프트웨어 아키텍처의 한 형식입니다.

 

더 자세하게는

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

 

 

# 뜬금 궁금증 - URI(Uniform Resource Identifier)와 URL(Uniform Resource Locator)의 차이

URI는 리소스를 고유하게 식별하는 문자열의 일반적인 형식을 의미합니다. URI는 인터넷 상의 모든 리소스를 식별하기 위한 표준화된 방법을 제공합니다. URI는 다음과 같이 두 가지 형태로 나타낼 수 있습니다.
1. URL (Uniform Resource Locator): 리소스의 위치를 포함합니다. 특정 리소스가 어디에 위치해 있는지를 가리키는 주소입니다.
2. URN (Uniform Resource Name): 리소스의 이름을 나타내며, 해당 리소스가 어디에 위치해 있는지를 명시하지 않습니다.

 

 

# REST의 구성요소

 

1. 자원(Resource): URI
모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재합니다.
자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 입니다.
Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청합니다.

2. 행위(Verb): HTTP Method
HTTP 프로토콜의 Method를 사용합니다.

3. 표현(Representation of Resource)
Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냅니다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있으며 JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다. (JSON을 많이 쓰는 이유는 브라우저 호환성이 좋기 때문입니다.)

 

 

# REST의 필요성

1. 애플리케이션 분리 및 통합
2. 다양한 클라이언트의 등장
3. 분산 시스템과 웹 서비스의 확장성

 

 

# REST의 특징

1. Server-Client(서버-클라이언트 구조)
   • 사용자 인증이나 context(세션, 로그인 정보) 등을 client가 직접 관리하고 책임집니다.
2. Stateless(무상태)
   • HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖습니다.  
   • 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해집니다.
   • 모든 요청은 독립적으로 시행됩니다.
3. Cacheable(캐시 처리 가능)
   • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.
4. Layered System(계층화)
   • API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있습니다.
   • PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있습니다.
5. Uniform Interface(인터페이스 일관성)
   • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행합니다.

 

 

# REST의 장단점

• 장점
  1. 간결하고 직관적인 설계
  2. 높은 확장성
  3. HTTP 프로토콜의 인프라를 그대로 사용
  4. 서버와 클라이언트의 명확한 분리
• 단점
  1. Stateless의 단점
  2. 세밀한 제어 어려움
  3. 보안의 어려움

 

 

# REST API란?

API (Application Programming Interface) - 직역해보면 응용프로그램 인터페이스입니다. 말 그대로 응용프로그램 간에 데이터를 주고받는 방법이라고 할 수 있습니다.

간단하게 REST 기반으로 서비스 API를 구현한 것입니다. REST는 그저 일종의 '방식'일 뿐입니다. 

 

 

# 뜬금 궁금증 - Interface, Protocol의 차이

공부를 해봤지만 이 개념은 굉장히 추상적이어서 간단하게 이해하기는 어렵습니다. 그래서 추후에 따로 포스트로 남기도록 하겠습니다.

 

 

# REST API 설계 규칙

1. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용
   Ex) http://restapi.example.com/houses/apartments   
2. URI 마지막 문자로 슬래시(/ )를 포함X
   1. URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용
   2. URI 경로의 마지막에는 슬래시(/)를 사용X
      Ex) http://restapi.example.com/houses/apartments/ (X)
3. 하이픈( - )은 URI 가독성을 높이는데 사용
4. 밑줄( _ )은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
   1. URI 경로에 대문자 사용X
   2. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
6. 파일확장자는 URI에 포함X
   1. REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함X
   2. Accept header를 사용
      Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
      Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
7. 리소스 간에는 연관 관계가 있는 경우
   1. /리소스명/리소스 ID/관계가 있는 다른 리소스명
      Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

 

 

# REST 방식 말고 다른 방식은 어떤것들이 있을까?

 

1. SOAP (Simple Object Access Protocol)
   SOAP는 웹 서비스 통신에 사용되는 XML 기반의 프로토콜입니다. RESTful API와 비교해 복잡하고 무겁지만, 보안 기능과 트랜잭션 관리를 포함하여 기능이 다양하게 제공됩니다. 주로 기업 간의 통신과 시스템 간의 통합에 많이 사용됩니다.
   
   
2. GraphQL (Graph Query Language):
   GraphQL은 페이스북에서 개발한 쿼리 언어로, 클라이언트가 원하는 데이터를 정확하게 지정하여 서버로부터 해당 데이터만을 요청할 수 있게 합니다. RESTful API와 비교해 클라이언트 측에서 요청한 데이터의 형태를 더 유연하게 제어할 수 있으며, 하나의 요청으로 여러 종류의 데이터를 가져올 수 있습니다.
   
   
3. gRPC (gRPC Remote Procedure Calls):
   gRPC는 구글에서 개발한 RPC 프레임워크로, Protocol Buffers를 기반으로 합니다. 클라이언트가 원격 서버의 메서드를 호출하는 방식으로 작동하며, 성능이 뛰어나고 작은 용량의 바이너리 데이터를 전송하기 때문에 효율적입니다. 주로 내부 서비스 간의 통신에 사용됩니다.
   
   
4. JSON-RPC
   JSON-RPC는 JSON을 사용하는 경량화된 RPC 프로토콜로, 클라이언트와 서버 간의 통신을 단순화하고 비동기적으로 호출하는 데 적합합니다.
   
   
5. WebSocket
   WebSocket은 양방향 통신을 위한 프로토콜로, 클라이언트와 서버가 지속적으로 연결을 유지하며 실시간 데이터를 주고받을 수 있습니다. 주로 실시간 채팅, 알림, 게임 등에 사용됩니다.
   
   
6. XML-RPC
   XML-RPC는 XML을 사용하는 간단한 RPC 프로토콜로, 클라이언트가 원격 서버의 메서드를 호출하는 방식으로 동작합니다.

생각보다 다양한  방식이 많습니다. 다음 포스트에서는 이 방식들과 REST 방식을 비교하여 어떠한 때에 어떤 방식을 채택하면 좋을지 알아보도록 하겠습니다.

 

 

 

 

 

 

# references

https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html  

chatgpt