TIL
22.10.18.나만 모르는 REST API 뽀개기!
개발따라김양
2022. 10. 18. 08:45
1. REST API란?
- REST 아키텍처 스타일을 따르는 API를 의미합니다.
2. REST(Representational State Transfer)란?
- HTTP의 장점을 최대한 활용할 수 잇는 아키텍처
- HTTP 프로토콜을 의도에 맞게 디자인하도록 유도
- HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처
- API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다
- 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.- CRUD Operation이란
CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로
REST에서의 CRUD Operation 동작 예시는 다음과 같다.- Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH) -> PUT 데이터의 모든 것을 업데이트/ PATCH 데이터의 일부를 업데이트
Delete : 데이터 삭제(DELETE)
HEAD : header 정보 조회(HEAD)
- Create : 데이터 생성(POST)
- CRUD Operation이란
- REST의 구성요소
- 자원(Resource) : HTTP URI(엔드포인트)
- 행위(Verb) : HTTP Method
- 표현 (Representations) : HTTP Message Pay Load
- REST의 특징
- Server-Client(서버-클라이언트 구조)
- REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
- Client : 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
- 서로에 대한 의존성 감소
- Stateless(무상태)
- Client의 context를 Server에 저장하지 않는다.
- Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
- Cacheable(캐시 처리 가능)
- 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
- Layered System(계층화)
- REST Server는 다중 계층으로 구성될 수 있다
- Uniform Interface(인터페이스 일관성)
- Server-Client(서버-클라이언트 구조)
- REST의 장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
- 단점
- 표준이 자체가 존재하지 않아 정의가 필요하다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)
- PUT, DELETE를 사용하지 못함
- pushState를 지원하지 않음
3. API란?
- 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의합니다.
- 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각할 수 있습니다.
4. REST API의 설계규칙
- URI는 리소스를 표현하는 데 중점을 두어야 한다
- URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다
- 도큐먼트 이름은 단수명사를 사용해야한다
도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념 - 컬렉션 이름, 스토어 이름은 복수명사를 사용해야 한다.
컬렉션 : 서버에서 관리하는 디렉터리라는 리소스
스토어 : 클라이언트에서 관리하는 리소스 저장소 - 마지막에 슬래시 (/)를 포함하지 않는다.
슬래시(/)는 계층 관계를 나타내는 데 사용한다. - 언더바 대신 하이폰을 사용한다.
하이폰(-)은 가독성을 높이는 데 사용한다 - 파일확장자는 URI에 포함하지 않는다.
- 행위에 대한 표현을 포함하지 않는다.
##bad
GET /getTodos/1
GET /todos/show/1
##good
GET /todos/1- 리소스에 대한 행위는 HTTP 요청 메서드로 표현한다
- 주로 5가지 요청 메서드를 사용하여 CRUD를 구현한다.
- 리소스에 대한 행위는 HTTP 요청 메서드로 표한하며 URI에 표현하지 않는다.
| HTTP 요청 메서드 | 종류 | 목적 | 페이로드 |
| GET | index/retrieve | 모든/특정 리소스 취득 | X |
| POST | create | 리소스 생성 | O |
| PUT | replace | 리소스의 전체 교체 | O |
| PATCH | modify | 리소스의 일부 교체 | O |
| DELETE | delete | 모든/특정 리소스 삭제 | X |
5. RESTful API란?
- 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스입니다.
- RESTful API는 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원합니다.
- REST 아키텍처를 구현하는 웹서비스를 RESTful 웹 서비스라고 합니다.
- 균일한 인터페이스는 모든 RESTful 웹 서비스 디자인의 기본입니다.
- 균일한 인터페이스의 아키텍처 제약 조건
- 요청은 리소스를 식별해야 합니다. 이를 위해 균일한 리소스 식별자를 사용합니다.
- 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있습니다.
서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족합니다. - 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신합니다.
이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송합니다. - 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신합니다.
이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송합니다.
- 균일한 인터페이스의 아키텍처 제약 조건
- RESTful API의 장점
- 확장성
- REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있습니다.
- 유연성
- RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원합니다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리합니다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않습니다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킵니다.
- 독립성
- REST API는 사용되는 기술과 독립적입니다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있습니다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있습니다.
- 확장성