REST API

REST?

REST 란, REpresentational State Transfer 의 약자이며, 웹 서비스의 설계 원칙과 패턴을 의미한다.

 

 

REST API

 

- restApi는 rest 아키텍스타일의 설계원칙을 준수하는 api를 말한다.

 

REST 설계 원칙에는 다음 6가지 원칙이 있다.

 

- Uniform-Interface (균일한 인터페이스)

    - 자원은 url로 식별 가능해야 된다.

    - url로 http method를 표현한다.

 

- State-less (무상태성)

    - 클라이언트의 요청은 독립적이어야 함.

    - REST API는 무상태성이기 때문에 각 요청에 필요한 모든 정보를 담아 전달해야 됨.

    - 작업을 위한 상태 정보를 따로 저장, 관리하고 있지 않다는 뜻.

    - 모든 필요한 정보는 요청에 담아 전달하기에 확장성과 신뢰성을 확보함.

 

- Cacheable (캐시 가능성)

    - 306 상태코드의 경우 캐시를 불러오는 것

    - 응답 헤더에 캐싱가능 여부를 넣어 전달함.

    - 네트워크 효율성을 높이고, 서버 부하를 줄이며 응답 속도를 개선 가능.

 

- Client-Server (클라이언트 - 서버의 분리)

    - 클라이언트와 서버를 분리함으로써 각각의 역할과 책임을 분리함.

    - 클라이언트 -> 사용자 인터페이스 및 사용자 경험 (UI, UX)

    - 서버 -> 데이터 저장 및 비즈니스 로직

    - 독립적인 개발과 확장성을 확보함.

 

- Layered System (계층화 시스템)

    - 여러 계층으로 시스템을 구성하여 각 계층의 역할에 집중할 수 있음.

    - 클라이언트는 중간 서버(로드 밸런서, 캐시 서버 등 )와 직접 상호 작용할 수 있음.

    - 각 계층은 서로 독립적이면서도 협력하여 전체 시스템의 확장성과 보안을 향상

 

- Code On Demand (코드 온 디맨드는 선택사항)

    - 서버가 클라이언트에 실행 가능한 코드를 전송하여 클라이언트의 기능을 확장할 수 있음.

    - 이는 선택 사항으로, 주로 웹 브라우저에서 JavaScript를 통한 동적 기능 확장 등에 활용.

    - 클라이언트가 사전에 구현해야 하는 기능을 간소화할 수 있음.

 

- URL 규칙

 

1. 리소스 중심의 URL 사용
URL은 동작(동사)이 아닌 리소스(명사)를 표현해야 함.

예를 들어, 사용자 정보를 조회할 때는 /users와 같이 리소스 이름을 사용.

 

2. HTTP 메서드 활용
CRUD 작업은 URL에 포함된 동사가 아니라 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 표현함.

예를 들어,

 

• GET :  /users → 사용자 목록 조회
• POST :  /users → 사용자 생성
• GET :  /users/{id} → 특정 사용자 조회
• PUT :  /users/{id} → 특정 사용자 정보 업데이트
• DELETE :  /users/{id} → 특정 사용자 삭제

 

3. 복수형 사용
일반적으로 리소스 이름은 복수형으로 표현하여 여러 개의 항목을 다룬다는 것을 명시함.

(예: /users, /orders)

 

4. 계층적 관계 표현
리소스 간의 관계를 표현할 때는 URL 계층 구조를 사용.

예를 들어, 특정 사용자의 주문 내역은 /users/{userId}/orders와 같이 표현할 수 있음.

 

5. 버전 관리 포함
API 버전 관리를 위해 URL에 버전 정보를 포함시키기를 권장함.

예를 들어, /api/v1/users와 같이 설계하여 API가 업데이트될 때 호환성을 유지할 수 있음.

 

6. 쿼리 파라미터 활용
필터링, 정렬, 페이징 등은 URL 경로가 아닌 쿼리 파라미터를 통해 전달함.

예를 들어, /users?sort=desc&limit=10과 같이 사용.

 

 

 

SOAP vs REST

 

SOAP (Simple Object Access Protocol)

• 프로토콜 기반: SOAP는 엄격한 표준과 프로토콜을 따르며, 메시지 포맷이 XML로 고정되어 있음.
• WSDL 활용: 서비스 인터페이스는 WSDL(Web Services Description Language)을 통해 정의되어, 클라이언트와 서버 간의 계약(contract)을 명확히 함.
• 내장 보안 및 트랜잭션 지원: WS-Security, WS-AtomicTransaction 등 다양한 확장 기능을 통해 보안 및 트랜잭션 관리가 내장되어 있음.
• 복잡성: 구조가 복잡하며, 상대적으로 무겁기 때문에 엔터프라이즈 환경이나 복잡한 비즈니스 로직을 가진 시스템에 적합.

 

REST (Representational State Transfer)

• 아키텍처 스타일: REST는 엄격한 표준이 아닌 아키텍처 스타일로, HTTP 프로토콜의 메서드(GET, POST, PUT, DELETE 등)를 활용하여 자원(Resource)에 접근.
• 유연한 데이터 포맷: XML뿐만 아니라 JSON, YAML, HTML 등 다양한 포맷을 사용할 수 있어 개발 및 통합이 간편함.
• 단순성과 경량성: REST는 설계 원칙(클라이언트-서버, 무상태성, 캐시 처리, 계층화 등)을 따르며 단순하고 경량 한 특성으로 빠른 개발과 확장이 용이함.
• 웹 친화적: HTTP 기반으로 설계되어 웹 애플리케이션과의 연동에 최적화되어 있으며, RESTful API는 URL 구조와 HTTP 상태 코드를 통해 직관적인 인터페이스를 제공.