API와 프로토콜

임지선·2024년 8월 29일

컴퓨터 네트워크

목록 보기

5/11

REST

REST(Representational State Transfer)는 웹 서비스 디자인을 위한 아키텍처 스타일입니다.
REST의 주요 목표는 웹의 장점을 최대한 활용하여 시스템 간의 상호작용을 간단하고 효율적으로 만드는 것입니다.

REST의 핵심 원칙

클라이언트-서버 구조 (Client-Server Architecture)

클라이언트와 서버는 분리되어 있으며, 클라이언트는 사용자 인터페이스와 사용자 경험을 책임지고, 서버는 데이터 저장과 처리의 책임을 집니다. 이 구조는 시스템의 유연성과 확장성을 높입니다.

무상태성 (Statelessness)

각 요청은 독립적이며, 서버는 요청의 상태를 저장하지 않습니다. 클라이언트가 요청할 때 필요한 모든 정보를 포함해야 하며, 서버는 요청을 처리하고 응답을 반환한 후에는 상태를 유지하지 않습니다.

캐시 가능성 (Cacheability)

서버의 응답은 캐시될 수 있어야 합니다. 이를 통해 서버의 부하를 줄이고, 클라이언트의 성능을 향상시킬 수 있습니다. HTTP 헤더를 사용하여 응답이 캐시 가능한지 아닌지를 명시할 수 있습니다.

계층화된 시스템 (Layered System)

시스템은 여러 계층으로 구성될 수 있으며, 각 계층은 특정 기능을 수행합니다. 클라이언트는 최종 서버와 직접 상호작용하는 것이 아니라, 중간 서버(프록시, 로드 밸런서 등)를 통해 상호작용할 수 있습니다.

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

시스템의 상호작용을 단순화하고 일관되게 유지하기 위해 표준화된 인터페이스를 제공합니다. 이는 REST의 가장 중요한 원칙 중 하나입니다.

자원 기반 (Resource-Based)

REST에서는 서버에서 자원(리소스)을 다루는 방식을 통해 상호작용합니다. 자원은 URL을 통해 식별되며, HTTP 메서드를 사용하여 조작됩니다.

REST 제약 조건

REST(Representational State Transfer)는 웹 서비스 디자인을 위한 아키텍처 스타일로, RESTful 시스템을 설계할 때 다음과 같은 제약 조건을 따릅니다. 이 제약 조건들은 REST 시스템의 유연성, 확장성, 성능을 극대화하기 위해 중요한 역할을 합니다.
이 제약 조건들은 RESTful 시스템이 높은 성능, 확장성, 유연성을 가지도록 보장하며, 클라이언트와 서버 간의 상호작용을 효과적으로 관리할 수 있게 합니다. 각 제약 조건은 서로 보완적이며, 함께 적용될 때 RESTful API의 장점을 극대화합니다.

1. 클라이언트-서버 구조 (Client-Server Architecture)

설명: 클라이언트와 서버는 독립적인 구조로 설계됩니다. 클라이언트는 사용자 인터페이스와 사용자 경험을 담당하고, 서버는 데이터 저장과 처리 기능을 담당합니다.
이점: 클라이언트와 서버의 분리를 통해 개발 및 유지보수의 효율성을 높일 수 있으며, 클라이언트와 서버의 독립적인 확장이 가능합니다.

2. 무상태성 (Statelessness)

설명: 각 요청은 독립적이어야 하며, 서버는 클라이언트의 상태를 저장하지 않습니다. 모든 요청은 필요한 모든 정보를 포함해야 합니다.
이점: 서버가 상태를 유지하지 않기 때문에 서버의 확장성과 복잡성을 줄일 수 있으며, 요청 처리가 단순화됩니다. 클라이언트가 요청을 다시 시도할 때 서버의 상태를 고려할 필요가 없습니다.

3. 캐시 가능성 (Cacheability)

설명: 응답은 캐시될 수 있어야 하며, 서버는 응답이 캐시 가능한지 여부를 명시할 수 있습니다. 캐시 관련 메타데이터는 HTTP 헤더를 통해 전달됩니다.
이점: 응답의 캐시를 통해 서버의 부하를 줄이고, 클라이언트의 성능을 향상시킬 수 있습니다. 이를 통해 네트워크 대역폭을 절약하고 응답 속도를 개선할 수 있습니다.

4. 계층화된 시스템 (Layered System)

설명: 시스템은 여러 계층으로 나눌 수 있으며, 각 계층은 특정 기능을 수행합니다. 클라이언트는 최종 서버와 직접 상호작용하지 않고, 중간 서버(프록시, 로드 밸런서 등)를 통해 상호작용할 수 있습니다.
이점: 계층화된 구조는 시스템의 유연성을 높이고, 보안 및 로드 밸런싱을 용이하게 하며, 시스템의 확장성과 관리성을 향상시킵니다.

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

설명: REST의 핵심 원칙 중 하나로, 시스템의 상호작용을 단순화하고 일관되게 유지하기 위해 표준화된 인터페이스를 제공합니다. 이는 자원의 식별, 자원에 대한 조작, 자원의 표현 방식 등을 표준화하여 일관된 방식으로 처리합니다.
이점: 일관된 인터페이스를 사용하면 클라이언트와 서버 간의 상호작용이 단순해지고, 시스템의 이해와 유지보수가 용이해집니다.

6. 자원 기반 (Resource-Based)

설명: REST에서는 자원이 웹 상의 엔티티로 간주되며, 각 자원은 고유한 URL로 식별됩니다. 자원은 HTTP 메서드를 통해 조작됩니다.

GET: 자원 조회
POST: 자원 생성
PUT: 자원 전체 업데이트
PATCH: 자원 부분 업데이트
DELETE: 자원 삭제

이점: 자원 중심의 접근 방식은 시스템의 설계를 단순화하고, 클라이언트가 자원을 일관되게 다룰 수 있도록 합니다.

RESTful API

RESTful API는 REST 원칙을 준수하는 API를 의미합니다.
RESTful API는 웹에서 클라이언트와 서버 간의 상호작용을 간단하고 일관되게 처리할 수 있도록 설계된 API입니다.

RESTful API 특징

자원(Resource) 식별

자원은 고유한 URL로 식별됩니다. 예를 들어, https://api.example.com/users/123는 ID가 123인 사용자 자원을 식별합니다.

HTTP 메서드 사용

자원에 대해 CRUD(생성, 읽기, 업데이트, 삭제) 작업을 수행하기 위해 HTTP 메서드를 사용합니다:
GET: 자원 조회
POST: 자원 생성
PUT: 자원 전체 업데이트
PATCH: 자원 부분 업데이트
DELETE: 자원 삭제

표준 HTTP 상태 코드

응답의 상태를 나타내기 위해 HTTP 상태 코드를 사용합니다. 예를 들어, 200 OK는 성공적인 요청을 의미하고, 404 Not Found는 자원을 찾을 수 없음을 의미합니다.

JSON 또는 XML 형식

데이터 전송 형식으로 일반적으로 JSON(JavaScript Object Notation)을 사용하지만, XML(eXtensible Markup Language)도 사용할 수 있습니다. JSON은 읽기 쉽고, 데이터 직렬화가 간편하여 많이 사용됩니다.

무상태성 (Stateless)

클라이언트의 요청은 서버가 상태를 유지하지 않기 때문에 모든 요청에 필요한 정보를 포함해야 합니다.

HATEOAS (Hypermedia As The Engine Of Application State)

클라이언트가 애플리케이션의 상태를 전이하는데 필요한 모든 정보를 응답에 포함시켜 제공하는 원칙입니다. 이를 통해 클라이언트는 응답을 기반으로 다음 동작을 결정할 수 있습니다.

URL, URI, URN

URL (Uniform Resource Locator)

URL(Uniform Resource Locator)은 자원에 접근하기 위한 주소를 정의합니다.
URL은 자원의 위치를 명시적으로 지정하며, 자원에 접근하는 방법(예: 프로토콜)을 포함합니다.

형식:

URL의 일반적인 형식은 다음과 같습니다.

scheme://host:port/path?query#fragment

예시: https://www.example.com:8080/path/to/resource?query=123#section1

scheme: 프로토콜(예: http, https, ftp)
host: 서버의 도메인 이름 또는 IP 주소
port: 네트워크 포트(선택적)
path: 자원의 경로
query: 쿼리 문자열(선택적)
fragment: 문서 내의 특정 부분(선택적)

목적:

자원의 위치를 정확히 식별하고, 자원에 접근하기 위한 방법을 제공합니다.

URI (Uniform Resource Identifier)

URI(Uniform Resource Identifier)는 자원을 식별하기 위한 문자열입니다.
URI는 자원에 대한 고유한 식별자를 제공하며, 자원을 식별할 수 있는 방법을 정의합니다. URI는 URL과 URN을 포함하는 상위 개념입니다.

형식:

URI는 두 가지 주요 형식을 포함합니다.

URL과 URN

목적:

자원에 대한 고유한 식별자를 제공하고 자원에 접근하거나 자원의 속성을 확인할 수 있는 방법을 정의합니다.

URN (Uniform Resource Name)

URN(Uniform Resource Name)은 자원의 고유한 이름을 제공하여, 자원을 식별하지만 그 자원의 위치나 접근 방법을 명시하지 않습니다.
URN은 자원의 영구적인 식별자를 제공하며, 자원 위치의 변경과 상관없이 자원을 식별할 수 있도록 설계되었습니다.

형식:

URN의 일반적인 형식은 다음과 같습니다.

urn:<namespace>:<identifier>
  
예시: urn:isbn:0451450523 (ISBN을 사용한 책의 식별자)

namespace: URN의 네임스페이스(예: isbn, doi)
identifier: 네임스페이스 내에서 자원을 고유하게 식별하는 문자열

목적:

자원을 고유하게 식별하며, 자원의 위치나 접근 방법은 명시하지 않습니다.

임지선

성장하는 프론트엔드 개발자입니다.

이전 포스트

웹 보안과 인증

다음 포스트