REST API

Yun·2024년 2월 21일
0

개인공부

목록 보기
6/28

REST란?

REST (Representational State Transfer)

  • HTTP 프로토콜로 데이터를 전달하는 프레임워크이다.

  • 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는다.

  • 클라이언트와 서버 간의 구성요소를 엄격히 분리하여 구현은 단순화하고 확장성과 성능을 높일 수 있다.

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

  • 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계에 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐이다.

어떻게 작동할까?

클라이언트는 리소스가 필요할 때 API를 이용해 서버에 접속한다.

  1. 클라이언트가 서버에 요청한다.
  2. 서버가 클라이언트를 인증하고 요청을 수행할 권한이 클라이언트에게 있는지 확인한다.
  3. 서버가 요청을 수신하고 처리한다.
  4. 서버가 클라이언트에게 응답을 반환한다. 응답에는 요청 성공여부와 클라이언트가 요청한 정보가 포함된다.

요청에 필요한 것은?

  • 자원(Resource): 고유 리소스 식별자

    • 일반적으로 URL을 사용해 리소스를 식별한다.
    • 클라이언트가 요구하는 사항을 서버에 명확하게 지정한다.
  • 행위(Verb): 메서드

    • 수행해야 하는 작업을 서버에 알려준다.
    • GET, POST, PUT, DELETE 등이 있다.
  • 표현(Representations): HTTP 헤더

    • 클라이언트가 요청하면 서버가 적절한 응답을 돌려준다.
    • 클라이언트와 서버 간에 교환되는 메타데이터이다.

Methods

  • GET

    • 자원을 받아오기만 할 때 사용한다.
    • 어떠한 방식으로도 자원의 상태를 변경시키지 않는다.
    • 멱등성(여러 번 호출해도 동일한 결과를 얻음)을 띈다.
  • POST

    • 새로운 자원을 추가할 때 사용한다.
    • 비멱등성으로, 동일한 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성한다.
  • PUT

    • 존재하는 자원을 변경할 때 사용한다.
    • POST는 여러 자원에 수행되는 반면, PUT은 단일 자원에만 수행된다.
    • 멱등성으로, 동일한 요청을 여러 번 전송해도 결과는 동일하다.
  • DELETE

    • 자원을 삭제할 때 사용한다.
    • 서버 상태를 변경하므로 적절한 인증이 없으면 사용할 수 없다.
    • 멱등성으로, 자원을 삭제한 후 반복적으로 요청하면 404 코드를 받는다.
  • PATCH

    • 한 자원의 데이터를 부분적으로 변경할 때 사용한다.
    • PUT은 자원을 완전히 대체하는 경우에 사용하고, PATCH는 존재하는 자원을 부분적으로 업데이트하기 위해 사용한다.
    • 모든 브라우저, 서버에서 지원하는 것은 아니다.

이점은?

  • HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 별도의 인프라를 구축할 필요가 없다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.
  • REST가 클라이언트-서버 상호작용을 최적화하기 때문에 효율적이다.
  • 성능을 저하시키는 병목 현상을 일으키지 않으면서 확장성을 지원한다.
  • 클라이언트-서버를 완전히 분리한다.
  • 각 부분이 독립적으로 발전할 수 있도록 서버 구성요소를 단순화하고 분리한다.
  • 서버 애플리케이션의 변경이 클라이언트 애플리케이션에 영향을 주지 않는다.

특징은?

  • Server-Client 구조

    • 서로 간 의존성이 줄어든다.
  • Stateless (무상태)

    • 클라이언트의 상태를 서버에 저장하지 않는다.
    • 서버는 각각의 요청을 별개의 것으로 인식하고 처리한다.
  • Cacheable (캐시 처리 가능)

    • HTTP 프로토콜을 그대로 사용하므로 캐싱 기능을 적용할 수 있다.
    • 캐시를 사용하여서버의 응답시간, 성능, 자원 이용률을 향상시킬 수 있다.
  • Layered System (계층화)

    • 서버를 계층화하여 클라이언트와 서버 사이에 다른 승인된 중개자를 연결할 수 있다.
    • 서버는 요청을 다른 서버로 전달할 수 있다.
    • 보안, 애플리케이션, 비즈니스 로직 등의 여러 계층으로 설계할 수 있다.
    • 모든 계층은 클라이언트에 노출되지 않는다.
  • Uniform (유니폼 인터페이스)

    • URI로 지정된 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
  • Self-descriptiveness (자체 표현 구조)

    • REST API 메시지만 보고도 쉽게 이해할 수 있다.

REST API란?

  • REST 기반으로 서비스 API를 구현한 것이다.
  • 설계 규칙은 다음과 같다.
    • '/'는 계층 관계를 나타내는데 사용한다.
    • URI 마지막 문자로 '/'를 포함하지 않는다.
    • '-'은 URI 가독성을 높이는데 사용한다.
    • '_'은 URI에 사용하지 않는다.
    • URI 경로는 소문자가 적합하다.
    • 파일 확장자는 URI에 포함하지 않는다.
    • 행위를 포함하지 않는다.

RESTful이란?

  • REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.

    • REST 원리를 따르는 시스템은 RESTful하다고 지칭된다.
  • REST의 설계규칙을 올바르게 지키는 REST API를 제공하는 웹 서비스이다.

  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로 한다.

  • REST를 사용했다고 하여 모두가 RESTful한 것은 아니다.

    • CRUD를 모두 POST로만 처리하는 API
    • route에 resource 외의 정보가 들어가는 경우 (/updateId)
    • RESTful API는 API의 이해도와 호환성을 높이기 위함이기 때문에, 성능을 중요시한다면 반드시 RESTful API를 구현할 필요는 없다.

출처

0개의 댓글