231201 TIL #257 네트워크 #4 REST / REST API / RESTful

김춘복·2023년 12월 1일
0

TIL : Today I Learned

목록 보기
257/328

Today I Learned

오늘은 항상 헷갈리던 REST에 대해 제대로 정리해보았다.


참고 사이트 : dev-coco

REST

REpresentational State Transfer
자원을 이름으로 구분해 해당 자원의 상태를 주고 받는 모든 것

  • 자원의 표현에 의한 상태 전달

  • 분산 시스템에서 자원을 나타내고, 자원에 대한 상태를 전송하기 위한 아키텍쳐 스타일.

  • URI와 HTTP를 이용한 통신 목적의 서버-클라이언트 아키텍처 스타일

  • 주로 HTTP 프로토콜을 사용하지만 그외 다양한 프로토콜을 지원할 수 있다.

구성요소

  • 자원 : Resource. 해당 SW가 관리하는 모든 것. URI로 식별된다.

  • 행위 : Verb. HTTP의 Method. CRUD(GET, POST, PUT, PATCH, DELETE)

  • 표현 : Representation. 그 자원을 표현하기 위한 이름
    클라이언트가 서버와 데이터를 주고받는 형태로 JSON, XML 등이 있다.

특징

  • Server - Client 구조
    자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트.
    클라이언트가 서버에 요청을 보내고, 서버가 클라이언트에게 응답을 보낸다.

  • Stateless
    클라이언트의 context(문맥)를 서버에 저장하지 않고, 그것 없이도 통신할 수 있다.
    서버는 각각의 요청을 별개의 것으로 인식하고 처리한다.

  • Cacheable
    서버의 응답 메세지는 캐싱(저장 후 재사용)할 수 있다.
    HTTP의 기능인 캐싱을 적용할 수 있어 대량의 요청을 효율적으로 처리한다.

  • 계층 구조(Layered System)
    REST 서버는 다중 계층으로 구성될 수 있다.
    보안, 로드밸런싱, 암호화 등을 위한 계층을 추가해 구조를 변경할 수 있다.(ex. Proxy, Gateway)
    중간 계층이 변경되어도 통신에 영향을 주지 않는다.

  • Uniform Interface
    URI로 지정한 자원에 대한 요청을 통일되고 한정적으로 수행한다.
    HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하며, 어떤 기술이나 언어에 종속되지 않는 느슨한 결합 형태를 가진다.

  • 주문형 코드 code on demand (선택)
    손쉬운 데이터 처리를 위해 서버는 클라이언트에서 실행될 스크립트를 전송할 수 있다.


REST API

REST의 특징을 기반으로 서비스 API를 구현한 것

  • 각 요청이 어떤 동작이나 정보를 위한 것인지 그 요청 자체로 추정이 가능하다.

  • URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시한다.

REST API 설계 규칙

  1. URI는 명사를 사용한다. 일반적으로 users같은 복수형의 명사를 쓴다.
    ex. URI에 find~ create~ 이런 동사형을 쓰지 않는다.

  2. /(슬래시)로 계층 관계를 표현한다.
    ex. /organizations/{orgId}/users/{userId}

  3. URI의 마지막 문자로 슬래시를 포함하지 않는다.

  4. _(언더바)를 사용하지 않고 -(하이픈)를 사용한다.

  5. URI는 소문자로만 구성한다.

  6. HTTP Status Code를 사용한다.

  7. 파일 확장자는 URI에 포함하지 않는다.


RESTful API

REST API의 설계 규칙을 잘 지켜 만든 API

  • self-descriptiveness : RESTful한 API는 요청을 보내는 주소만으로 어떤걸 요청하는지 파악이 가능하다. API 그 자체만으로 API의 목적을 쉽게 알 수 있다.
profile
꾸준히 성장하기 위해 매일 log를 남깁니다!

0개의 댓글