REST & REST API

REST (REpresentational State Transfer)

• REST란?

  • 로이 필딩(Roy Fielding)이 2000년 박사 학위 논문에 정의한 네트워크 소프트웨어 아키텍처
  • '네트워크에서 통신을 구성할 때 이런 구조로 설계하라는 지침'
  • 자원(Resource)의 상태 전이(State Transfer)를 표현(Representation) 하기위한 소프트웨어 아키텍쳐
  • 조건 참고: https://namu.wiki/w/REST

• REST API

  • REST는 네트워크 통신을 위해 제시되었으나, 온라인 '네트워크'의 지분 중 태반을 차지하는 '웹' 기반의 전송을 위해 쓰이는 경우가 대부분 -> REST API
  • Resource(자원)
    파일, 문서, 데이터 등을 모두 포함하지만
    우리는 Domain model에 대한 데이터를 응답하는 어플리케이션을 개발하므로
    Domain Model이 Resource(자원)라고 볼 수 있다.
  • Representation(표현)
    HTTP를 사용하므로 HTTP Protocol을 활용해 표현한다.
    • URI - 를 통해 Resource 이름을 표현한다 (/Posts)
    • Method - HTTP Method를 통해 상태를 변경하는 행위를 표현한다.
      (GET, POST, PUT, PATCH, DELETE...)
    • JSON, XML.. - 등 을 통해 Resource의 상태를 표현한다.
  • REST style API 디자인 가이드
    • URI, 즉 Resource의 이름은 명사, 소문자, 복수형 사용을 권장
      ex) /posts
    • / 를 통해 Resource의 계층 관계를 표현
      ex) /posts/{id}/comments
    • 마지막에 / 를 포함하지 않는다.
    • 언더바( _ ) 는 사용하지 않아야하고 가독성을 높이려면 하이픈( - )을 사용
      ex) /posts/{id}/long-comments
    • 특정 Resource 하나를 가져올 때에는 해당 Resource의 Identifier를 포함하여 표현
      ex) /posts/{id}
    • Resource 목록의 페이징, 필터링, 정렬, 검색 을통해 가져올 때는 QueryParameter활용
      ex) /posts?page=12&order=latest

• RESTful API 란?

  • REST규칙을 아주 잘 지킨다는 말
  • 일반적으로 얼마나 REST한지를 평가할 때
    Leonard Richardson의 성숙도 모델(Maturity Model)을 참고
    위 정도의 REST API가 level2, + HATEOS를 잘 지킨단계 = level3
  • 개인마다 정의가 다르지만 일반적으로 level3 까지 준수할 때 RESTful 하다고 말함
    (level3 를 지킬 때 클라이언트는 응답 만으로 다음 행위를 판단할 수 있다
    (상태의 변화를 한정시키는 것))