Representational State Transfer ful API

  • RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다

  • REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다

  • REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.

  • 주로 사용언어와 상관없이 모두 읽을 수 있는 JSON을 사용한다

REST ful API 가 되기 위한 조건

  • 클라이언트, 서버 및 리소스로 구성되어 있으면서 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처

  • 요청 간 클라이언트 정보가 저장되지 않고, 각 요청이 분리되어 서로 연결되지 않아야 한다

  • 클라이언트-서버 간 상호작용을 간소화하는 캐시 가능 데이터

  • 정보가 표준형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스

    • 요청된 리소스가 식별가능하고, 클라이언트에 전송된 표현과 분리되어야 한다
    • 요청받은 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 한다
    • 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야하는지에 대해 충분한 정보가 포함되어야 한다
    • 클라이언트가 리소스에 엑세스한 후, 하이퍼링크를 사용해 현재 수행가능한 기타 모든 작업을 찾을 수 있어야 한다
  • 요청된 정보를 검색하는데 관련된 서버의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화되어야 한다

  • (optional) 요청을 받으면 서버에서 클라이언트로 실행가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능

CRUD Operation

  • Create : 생성(POST)
  • Read : 조회(GET)
  • Update : 수정(PUT)
  • Delete : 삭제(DELETE)
  • HEAD: header 정보 조회(HEAD)

REST API 장점

  • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다

  • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다

  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다

  • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다

  • REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다

  • 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다

  • 서버와 클라이언트의 역할을 명확하게 분리한다

REST API 단점

  • 표준이 존재하지 않는다
  • 사용할 수 있는 메소드가 4가지 밖에 없다
  • HTTP Method 형태가 제한적이다
  • 브라우저를 통해 테스트할 일이 많은 서비스라면
  • 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다
  • 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다
  • PUT, DELETE를 사용하지 못한다
  • pushState를 지원하지 않는다

REST 구성 요소

  • 자원(Resource): URI
  • 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다
  • 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다
  • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다
  • 행위(Verb): HTTP Method
  • HTTP 프로토콜의 Method를 사용한다
  • HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다

REST API 설계

profile
틀린 내용이나, 개선해야 할 사항을 발견하신다면 댓글로 편하게 남겨주세요. 감사합니다.🙇

0개의 댓글