[API] REST API ?

[ REST API는 Representational State Transfer의 약자이다 ]

 

 

REST API는 웹 서비스 간의 상호 작용을 위한  1아키텍처 스타일이에요!

이 아키텍처를 사용하는 API는 HTTP 프로토콜을 기반으로 데이터를 교환하고, Resource(자원)의 상태를 Transfer(전달)하는데 Representaion(표현)을 사용합니다. REST API의 주요 특징은 다음과 같습니다. 

 

 

 

 

1. REST API 특징

 

1-1. 상태없음(Stateless) : 서버가 클라이언트의 상태를 저장하지 않습니다. 각 요청은 독립적이고, 필요한 모든 정보는 그 요청 내에 포함되어 있어야 해요. 

1-2. 자원 기반(Resource-Based) : REST API는 자원(예를 들면, 사용자, 문서, 이미지)을 중심으로 설계되고, 각 자원은 고유한 URI(Uniform Resource Identifier)을 통해 접근할 수 있습니다. 

1-3. 표준 방식: API는 표준 HTTP메서드를 사용합니다(예를 들면, Get, Post, Put, Delete) 각각의 메서드는 자원에 대한 다른 작업을 나타내죠.

1-4. 표현 : 클라이언트와 서버 사이에 데이터 교환 시, 자원의 상태는 JSON, XML, HTML 등과 같은 형식으로 표현됩니다. 

1-5. 계층화 시스템 : REST API는 프록시, 게이트웨이와 같은 다양한 계층을 통해 서비스 될 수 있어서, 아키텍처의 확장성과 보안을 강화해요. 

1-6. 코드 온 디맨드(선택사항) : 서버는 실행 가능한 코드를 클라이언트에게 전송하여 클라이언트의 기능을 일시적으로 확장할 수도 있어요.

 

 

 

 

2. REST API은 언제 사용될까?

 

2-1. 소셜 미디어 서비스에서 데이터(게시물, 댓글, 프로필)을 조회하거나 게시하는 기능

 

2-2. 온라인 쇼핑 애플리케이션에서 상품 목록을 가져오거나 주문을 생성하는 기능 

 

2-3. 클라우드 서비스에서 사용자 데이터를 관리하거나 서비스 설정을 변경하는 기능

 

 

 

---

 

 

REST API는 웹기반 클라이언트 - 서버 애플리케이션을 개발할 때 광범위하게 사용되고,

기술 스택이 다른 시스템간에도 호환되는 방식으로 정보를 교환할 수 있는 유연하고, 간단한 방법을 제공하는 아키텍서 스타일입니다. 

 

 

"웹 기반의 애플리케이션 개발"

예를 들면, 웹 기반의 애플리케이션(웹사이트, 클라우드 서비스)을 개발할 때

클라이언트(사용자의 웹 브라우저나 모바일 앱)와 서버(데이터를 처리하고 저장하는 시스템)은 HTTP프로토콜을 사용해서 데이터를 주고 받는데요. REST API를 사용하여 보다 쉽게 데이터를 주고 받을 수 있고, 개발자들은 서로 다른 환경에서 작동하는 애플리케이션 간의 통합을 보다 쉽게 할 수 있어요. 

 

"기술 스택이 다른 시스템?" 

예를 들면, 한쪽은 자바, 한쪽은 파이썬으로 각 시스템이 개발되었을 때 

두 시스템 모두 REST API를 통해 데이터를 주고받을 수 있어요. REST API는 다양한 기술로 구축된 시스템 간에도 잘 동작하는 장점을 가지고 있어, 서로 다른 시스템이 통신하기 위한 표준화된 방법을 제공하죠. 

 

 

 

---

1아키텍처 스타일

 

1-1. 아키텍처란?소프트웨어의 기본적인 구조와 시스템의 컴포넌트들, 그들의 관계, 그리고 환경과의 상호작용을 정의하는 고수준의 설계 청사진입니다.

 

 

1-2. 아키텍처 스타일이란?

소프트웨어 아키텍처를 설계하는 데 사용되는 일련의 규칙, 제약사항, 지침들을 의미합니다. 

이러한 스타일은 아키텍처의 구조와 행동을 규정하고, 컴포넌트들이 어떻게 상호작용할지, 정보가 어떻게 흐를지, 시스템의 재사용성이나 확장성이 어떻게 될지 등을 결정해요. 일반적인 아키텍처 스타일은 다음과 같습니다. 

 

1-2-1. 계층형 아키텍처(Layered Architecture) : 시스템을 여러 계층으로 나누며, 각 계층은 특정한 역할을 가지고 있습니다. 예를들면, 프레젠테이션 계층, 비즈니스 로직 계층, 데이터 엑세스 계층 등이 있죠.

1-2-2.이벤트 기반 아키텍처(Event-Driven Architecture) : 이벤트 생성과 이벤트 처리를 중심으로 구축되며, 이벤트는 시스템의 다른 부분으로 전파되어 처리됩니다. 

1-2-3. 마이크로서비스 아키텍처(Microservices Architecture) : 작고 독립적으로 배포 가능한 서비스의 집합으로 시스템을 구성하며, 각 서비스는 특전 비즈니스 기능을 담당해요. 

1-2-4. RESTful 아키텍처(RESTful Architecture) : 웹서비스에 사용되며, REST 아키텍처 원칙에 따라 설계됩니다. 리소스 중심으로 구축되고, HTTP 메서드를 사용하여 리소스 상태를 전송합니다. 

1-2-5. 서비스 지향 아키텍처(Service-Oriented Architecture = SOA) : 서비스를 기반으로 시스템을 구축하며, 서비스는 재사용 가능하고, 네트워크를 통해 접근 가능해요. 

 

 

즉, 아키텍처 스타일은 시스템의 요구사항과 목표에 맞춰 선택되고, 효율성, 확장성, 유지보수성, 재사용성과 같은 시스템 특성에 영향을 미칩니다. 

 

 

 

---

 

REST API 설계 규칙 

좋은 REST API 설계를 위해서는 '유지보수가 쉽고', '확장성이 뛰어나며', '사용하기 편리'해야 합니다. 

 

 

1. 자원 기반 URL사용

REST API는 자원(Resource)기반으로 URL을 구성해야합니다. 

예를 들어, 사용자에 대한 정보를 다루는 경우 URL은 '/users'와 같이 될 수 있습니다. 

 

 

 

2. 슬래시 구분자(/)

• 주로 URL에서 자원의 계층구조를 표현하는 데 사용됩니다. 

이 구분자는 URL을 명확하고 읽기 쉽게 만들며, 자원 간의 관계를 직관적으로 나타내는 데 도움이 됩니다. 

실무 적용 예시는 다음과 같습니다. 

2-1. 상품 목록 조회 : /product

https://restapi.com/product 

2-2. 특정상품 조회 : /product/123

https://restapi.com/product/123

 

• URL 마지막 문자로 슬래시 구분자(/)를 포함하지 않습니다. 

일반적으로 URL의 마지막에 슬래시를 포함하지 않습니다. 

예를 들어,

' /users/1234/product/ ' (X) 보다는

' /users/1234/product '  (O) 이 더 일반적입니다. 

즉, REST API는 분명한 URL를 사용하여 통신을 해야하기 때문에, 혼동을 주지 않도록 하는 것이 좋아요. 

 

• 과도한 계층을 구조를 사용하지 않는다. 

너무 많은 계층을 URL에 포함시키지 않는 것이 좋아요. T

이는 URL을 복잡하게 만들고 사용자에게 혼란을 줄 수 있기 때문입니다. 

예를 들어, https://restapi.com/product/users/123/goods/23i4/1igow/12133/143i5/members/photo (x)