[REST API] REST & RESTful API

최진민·2022년 1월 3일
post-thumbnail
  • REST
  • REST API
  • RESTful

REST


REST ?

  • Representational State Transfer
  • 자원을 이름으로 구분하여 상태(정보)를 주고 받는 것
    • 자원(resource)의 표현(representation)에 의한 상태 정보 전달
      • 자원
        • 소프트웨어가 관리하는 모든 것 (ex) 문서, 그림, 데이터 등)
      • 표현
        • 자원을 표현할 수 있는 이름 (ex) db 중, 학생 정보 => students)
      • 상태(정보) 전달
        • 데이터 요청 시점에 정보가 전달된다.
        • 일반적으로 JSON, XML를 통해 송수신
  • WWW (World Wide Web)과 같은 분산 하이퍼 미디어 시스템을 위한 SW 개발 아키텍처
    • 기존 웹 기술 + HTTP을 그대로 활용하기 때문에 웹의 장점을 최대한 활용 가능

구체적인 개념

  • HTTP URI를 통해 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는하는 것
    • CRUD
      • 생성(Create, POST)
      • 조회(Read, GET)
      • 수정(Update, PUT)
      • 삭제(Delete, DELETE)
      • 헤더 정보 조회(HEAD, HEAD)
  • REST = 자원 기반 구조 (ROA, Resource Oriented Architecture) 설계의 중심에 자원(Resource)이 있고 HTTP Method를 활용하여 자원을 처리한다.

장 / 단점

  • 장점
    1. HTTP를 그대로 사용하기 때문에 별도로 REST API 인프라를 구축할 필요가 없다.
    2. HTTP를 사용하는 모든 플랫폼에서 사용 가능
    3. 범용성 보장 (HyperMedia)
    4. 메시지가 의도하는 바를 명확히 표현 가능
    5. 서버와 클라이언트의 역할을 명확히 구분
  • 단점
    1. 표준이 존재하지 않는다.
    2. 메소드는 HTTP Method로 국한된다.
    3. 구형 브라우저에서 지원하지 않는 PUT, DELETE

필요성

  • 애플리케이션의 분리 및 통합
  • 다양한 클라이언트 종류
    • 다양한 모바일 및 웹 클라이언트와 소통이 가능하다.

⭐️ 구성 요소

  1. 자원 (Resource) : URI (Uniform Resource Identifier)
    • 모든 자원은 고유의 식별자 값(ID)이 존재하며, 서버에 담긴다.
    • ID의 형태는 /a/a_id와 같이 URI의 형태
    • 클라이언트는 URI를 통해 자원을 지정하고, 서버에게 자원에 대한 조작을 요청
  2. 행위 (Verb) : HTTP Method
    • HTTP Method(POST, GET, PUT, DELETE 등)를 필요에 따라 사용하여 서버에게 요청
  3. 표현 (Representation)
    • 클라이언트가 자원을 조작하는 요청을 보낼 때, 서버는 응답한다.
    • 보통, JSON, XML, TEXT, RSS 등으로 자원이 표현된다.

특징

  1. 서버 - 클라이언트
    • 자원을 갖는 Server, 자원에 대한 조작을 요청하는 Client
      • Server : API를 제공한다. 비즈니스 로직 담당
      • Client : 사용자 정보(context)를 관리하고 책임진다.
    • 서로의 의존성 감소
  2. Stateless (무상태)
    • HTTP이 Stateless -> REST도 Stateless
    • 클라이언트의 context(쿠키, 세션 등)을 서버에 저장하지 않는다.
    • 서버는 클라이언트의 각 요청을 별개로 인식하고 처리
      • 전 요청이 후 요청에게 연관되어서는 안된다.
      • DB를 수정하여 DB에 의해 의한 수정은 허용
      • 일관성, 자유도 상승
  3. Cachable
    • HTTP 인프라를 그대로 사용하므로 캐싱 기능 또한 가능하다.
    • Last-Modified 태그E-Tag를 이용하면 캐싱 구현이 가능하다.
    • 대량 요청을 처리하기 위함
  4. 계층화 (Layered System)
    • 클라이언트는 서버의 REST API만을 호출
    • 서버를 다중 계층으로 구성할 수 있다.
      • 비즈니스 로직을 처리하는 서버
      • 그 앞단에 보안, 로드 밸런싱 등을 통해 시스템의 유연성과 확장성, 보안성을 상승시킬 수 있다.
  5. 인터페이스 일관성
    • 자원 조작은 한정적이고 일관적인 인터페이스를 통해 조작된다.
    • HTTP 표준을 사용하는 모든 플랫폼에서 사용 가능


REST API


REST API ?

  • API (Application Programming Interface)
    • 데이터와 기능의 집합을 통해 정보를 교환한다.
  • REST API
    • REST 기반의 API
    • 특히, 현대의 OpenAPI 및 마이크로서비스 아키텍처에서 주로 사용된다.

특징

  • 확장성과 재사용성을 높여 유지보수가 유연해진다.
  • HTTP를 지원하는 클라이언트, 서버 애플리케이션을 구현할 수 있다.

⭐️ 설계 규칙

  • Document : 객체의 인스턴스, 데이터베이스의 레코드
  • Collection : 서버에서 관리하는 Directory(자원)
  • Store : 클라이언트에서 관리하는 자원 저장소

기본

  1. URI는 자원의 정보를 표현하자 !
    • 동사 -> 명사 / 대문자 -> 소문자
    • Document -> 단수 명사
    • Collection -> 복수 명사
    • Store -> 복수 명사
    • ex) GET /Member/1 -> GET /members/1
  2. 행위는 HTTP Method로 표현하자 !
    • URI에 메소드를 표현하지 말자
      • ex) GET /members/delete/1 -> DELETE /members/1
    • URI 행위에 대한 동사를 넣지 말자
      • ex) GET /members/show/1 -> GET /members/1
    • 변하는 부분은 유일한 값(ID)로 표현하자
      • ex) student 생성 POST /students
      • ex) 특정 student 삭제 DELETE /students/1

심화

  1. /는 계층 관계를 표현
    • ex) http://restapi.ex.com/names/last
    • 특히, 마지막에는 넣지 않는다.
  2. -(하이픈)은 가독성을 위해 사용, _(언더 라인)은 사용하지 말자
  3. URI 경로는 소문자
  4. 파일 확장자는 URI에 포함하지 않는다.
    • Accept Header를 사용한다.
    • ex) http://restapi.ex.com/names/last/1/img.jpg (X)
    • ex) GET /names/last/1/img HTTP/1.1 HOST:restapi.ex.com Accept: image/jpg (O)
  5. 리소스간 연관관계가 있는 경우는 아래처럼 하자.
    • /리소스/리소스 ID/관계된 다른 리소스
    • ex) GET /members/1/devices

예시

설명 (CRUD)HTTP Method경로
모두 조회GET/resources
단일 조회GET/resources/:id
생성POST/resources
수정PUT/resources/:id
삭제DELETE/resources/:id

(참고) 응답 상태 코드

  • 1xx : 전송 프로토콜 수준의 정보 교환
  • 2xx : 요청 성공
  • 3xx : 클라이언트는 요청을 위해 추가적으로 행동을 취해야 함
  • 4xx : 잘못된 요청
  • 5xx : 서버 오류


RESTful


RESTful ?

  • RESTful하다. = REST API를 제공하다.
  • 공식적인 것이 아니다. REST를 REST 답게 쓰기 위함.

목적

  • 이해사용이 쉬운 REST API를 만들기 위함
  • RESTful 한 API 구현은 성능 향상이 목적이 아니라, 일관된 컨벤션을 통한 유연성호환성을 높이기 위함이다.

RESTful 하지 않다.

  • CRUD를 모두 POST만 사용할 때
  • URI 경로에 resource, id외의 정보가 들어가있을 때
    • ex) PUT /users/updatedName

출처 : Heee's Development Blog

profile
열심히 해보자9999

0개의 댓글