[Web] REST API

 

REST API란 REST를 기반으로 만들어진 API를 의미한다. 

 

REST(Representational State Transfer) API는 웹 서비스 통신을 위한 아키텍처 스타일 중 하나로, 웹 애플리케이션 간의 상호 작용에 사용되는 표준화된 방식이다. 특정한 규칙과 형식을 토대로 HTTP 프로토콜을 활용해 자원을 주고 받는 방식을 의미한다.

 

서비스에서 다루는 데이터나 기능을 리소스(자원)으로 표현한다. 

ex /users, /products와 같은 형태의 고유한 URL(엔드포인트)로 접근할 수 있다. 

URI = 리소스 식별자, URL = 리소스 식별자 + 경로

API는 경로만 보고도 어떤 자원에 접근하는지 직관적으로 알 수 있다.

 

표준화된 응답 형식
REST API는 응답을 주로 JSON 또는 XML 형태의 표준화된 포맷으로 전송한다. 특히 JSON은 가볍고 가독성이 좋아 REST API 설계 시 많이 사용된다. 이를 통해 다양한 클라이언트(브라우저, 모바일 앱, IoT 기기)에서 쉽게 처리 가능하다

 

• URI (Uniform Resource Identifier)를 통해 리소스를 명시하고
• HTTP Method(GET, POST, PUT 등)를 통해
• 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

REST의 동작 예시는 다음과 같다. HTTP 메서드를 일관되게 사용함으로써 API 사용자가 쉽게 의도를 파악하고 사용법을 이해할 수 있다.

• Create : POST
• Read : GET
• Update : PUT, PATCH
• Delete : DELETE

 

리소스 설계

REST API를 설계할 때는 행위보다 리소스에 초점을 맞춘다. 

• GET /users : 모든 사용자 조회
• GET /users/123 : ID가 123인 사용자 조회
• POST /users : 새로운 사용자 생성
• PUT /users/123 : ID가 123인 사용자 정보 전체 갱신
• DELETE /users/123 : ID가 123인 사용자 삭제

리소스와 메서드를 결합하면 API의 의미가 명확해지고 RESTful한 원칙을 따르는 구조가 된다.

 

REST의 구성요소

• 리소스(자원) : URI
• 자원에 대한 행위(Verb) : HTTP Method
• 자원에 대한 행위의 내용 : HTTP Message Pay Load

 

REST의 특징

• Server-Client (서버 - 클라이언트 구조)
  클라이언트와 서버의 관심사를 명확히 분리한다. 클라이언트는 UI/UX를 담당하고, 서버는 데이터 저장 및 로직 처리를 담당하여 역할이 명확해진다. 이를 통해 한 쪽에서 변경이 발생해도 다른 쪽에 미치는 영향이 최소화된다.
  
  
• Stateless (무상태)
  서버는 클라이언트의 상태를 저장하지 않는다 모든 요청은 필요한 인증 정보나 상태 정보를 자체적으로 포함해야하며, 서버는 각 요청을 독립적인 트랜잭션으로 처리한다. 서버의 스케일 아웃이 용이해지고, 부하 분산 및 장애 대응이 쉬워진다.
  
  
• Cacheable (캐시 처리 가능)
  클라이언트 혹은 중간 프록시가 요청에 대한 응답을 캐시할 수 있어야 한다. HTTP 캐시 제어 헤더를 활용해 클라이언트가 응답을 효율적으로 재활용하도록 장려한다/
  
  
• Layered System (계층화)
  시스템은 여러 계층을 통해 구성될 수 있으며, 각 계층은 서로의 존재를 알 필요가 없다. 
  ex: 클라이언트는 중간에 로드 밸런서, 프록시 서버가 있는지 알 필요가 없다 
  계층 구조를 통해 보안, 성능 최적화, 로깅, 라우팅 등의 기능을 유연하게 추가할 수 있다.
  
  
• Uniform Interface (인터페이스 일관성)
  클라이언트와 서버 간 통신을 표준화하고 단순화 하는 핵심 제약 조건이다. 
  자원식별 : 모든 자원은 URI를 통해 고유하게 식별된다.
  표현을 통한 자원 조작 : 클라이언트는 서버가 반환하는 표현(JSON, XML)을 통해 자원을 생성, 수정, 삭제할 수 있다.
  자기 서술적 메세지 : 요청 및 응답 메세지에는 컨텐츠 타입, 캐시 지시자, 인증 정보 등 필요한 정보를 충분히 담고 있어야한다.
  HATEOAS : 응답 내에 관련된 다른 자원이나 상태 전이를 위한 링크를 포함하여 클라이언트가 동적으로 탐색하고 상호 작용할 수 있도록 한다.  
• Code on Demand(필수는 아니다 선택사항)
  서버는 클라이언트에게 실행 가능한 코드를 전송하여 클라이언트 측에서 기능을 확장할 수도 있다.
  (자바 스크립트 파일)

 

REST의 장단점

장점

• 단순하고 직관적이며 웹 표준을 적극 활용
• 언어와 플랫폼 독립적
• 확장성, 유연성, 세계적으로 검증된 패턴
• 폭넓은 지원과 도구 생태계

단점

• 복잡한 질의나 대량의 데이터 검색 시, API 엔드포인트가 비대해질 수 있음
• 실시간 상호 작용이나 클라이언트 주도형 스키마에는 다소 부적합
• 특정 상황에서 HATEOAS 실천은 구현 난이도 증가

 

REST API의 설계 예시

• URI는 동사보다 명사를 대문자보다는 소문자를 사용한다
• 마지막에 슬래시를 포함하지 않는다
  ex : https://www.xxxx.com/asb/ << 마지막 / 를 포함하지 않는다
• 언더바 대신 하이픈을 사용한다
  ex : https://www.xxx.com/asb/develop-blog
• 파일확장자는 URI에 포함하지 않는다
  ex : xxx.com/image.jpg << 파일 확장자는 제외한다.
• 행위를 포함하지 않는다
  (HTTP Method)

이러한 REST API를 제공하는 것이 RESTful한 API라고 할 수 있다

 

출처: https://hahahoho5915.tistory.com/54