현대 웹 사이트들이 보통 채용하는 형태의 REST API 형태 .
도대체 REST API란 무엇이며, 왜 사용하는 것일까?
따라쓰더라도 확실히 알고 쓰는 것이 중요하다. 한번 알아보자.

REST API의 탄생

REST는 Representational State Transfer의 약자이다.
이는 웹의 설계가 HTTP의 우수성에 비해 제대로 쓰이지 못하는 걸 본
HTTP의 주요 저자 중 한명인 Roy Fielding에 의해 처음으로 발표된 개념이다.

HTTP를 사용하는 웹의 장점을 최대로 활용할 수 있는 아키텍쳐로 발표되었다.
여러가지 규칙을 두어, 클라이언트와 웹의 원활한 통신을 돕는다.
또한 균일한 인터페이스를 통해, 모든 언어가 동일한 형식에 맞춰 웹을 작성한다.

REST의 구성

  • 자원(Resource) : URI에 표현 된다.
  • 행위(Verb) : HTTP Method로서 표현 된다.
  • 표현(Representation) : HTTP Message Payload에 담긴다.

REST의 특징

  1. Uniform : 인터페이스의 일관성
  2. Stateless : 무상태(HTTP)
  3. Cacheable : 캐시 가능(Last-Modified, E-Tag)
  4. Self-Descriptiveness : 그 자체로 기능이 설명된다.
  5. Client - Server 구조
  6. 계층형 구조
  • 장점
    • HTTP의 인프라를 그대로 사용하므로, 따로 구축할 필요가 없다.
    • HTTP를 최대한 활용하여 추가적인 장점을 함께 가져갈 수 있다.
    • HTTP를 채용하는 모든 플랫폼에서 사용이 가능하다.
    • Rest API 자체가 의도하는 바를 명확히 드러내므로, 쉽게 파악할 수 있다.
    • Server와 Client의 역할을 명확하게 분리해준다.
  • 단점
    • 표준이 따로 존재하지 않아 정의를 해야한다.
    • HTTP 자체 메서드의 형태가 제한적이다.
    • Header 정보의 값을 처리해야할 일이 많으므로 전문성이 요구된다.

REST API Design

API를 REST형태로 설계할 때, 가장 중요한 항목은 2가지이다.

  1. URI는 정보의 Resource를 명사의 형태로 표현한다.
  2. 자원에 대한 행위는 HTTP Method로 표현한다.
    • ex) GET /members/delete/1
    • ex) DELETE /members/1
    • 당연히 아래쪽이 더 RESTful한 설계라고 볼 수 있다.

단, 설계 시 주의할 점이 몇 가지 있다.

  1. 슬래시(/)는 계층 관계를 나타낼 때 사용한다.
  2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
  3. 하이픈(-)은 URI 가독성을 높이는데에 사용한다.
  4. 밑줄(_)은 URI에 사용하지 않는다.
  5. URI 경로는 소문자가 적절하다.
  6. 파일 확장자는 URI에 포함시키지 않는다.