[Back-End] REST, REST API, RESTful API 란?

REST

- "Representational State Transfer" 약자로 웹에 존재하는 모든 자원(문서, 이미지, 동영상 등)에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론
- HTTP Method(GET, POST, PUT, DELETE)를 통해 CRUD(Create, Read, Update, Delete) 연산을 수행함

  ˙ GET(정보 조회)

  ˙ POST(새로운 정보 추가)

  ˙ PUT(정보 업데이트 및 교체)

  ˙ DELETE(지정한 정보 삭제)

-  Key/Value Pair 인 JSON 객체를 주로 사용함

 

예)

-------------- Request -----------------
GET api.mightyotter.com/otters HTTP/1.1
----------------------------------------
         |         |        |
         V         V        V 
-------------- Response ----------------
[
  {
    index : 0,
    name : dolce,
    age : 2,
  },
  {
    index : 1,
    name : latte,
    age : 1,
  },
  {
    ...
  }
]
----------------------------------------

 

REST 규칙 6가지

Uniform Interface
- 일관성있는 인터페이스로 URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
- HTTP 표준 프로토콜에만 따른다면 모든 플랫폼(특정 OS나 특정 언어에 종속된 것이 아닌)에서 사용이 가능함

Client-Server
- 자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트로 클라이언트-서버 구조를 갖음
- REST 서버는 API를 제공하고 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보 등)을 직접 관리함
- 클라이언트와 서버의 역할이 구분되어 개발 내용이 명확해지고 의존성이 줄어듦

Stateless
- HTTP 프로토콜이 Stateless Protocol인 것과 마찬가지로 REST도 무상태성을 갖음
- 클라이언트의 세션과 쿠키같은 컨텍스트를 서버에 저장하지 않으므로 서버 구현이 단순함

Cacheable
- 웹 표준을 따라 웹의 인프라를 사용할 수 있으므로 캐싱 기능을 적용할 수 있음
- HTTP에서 사용하는 Last-Modified나 E-Tag를 사용해 구현할 수 있음
- 일반적인 서비스에서 조회 기능이 많이 사용된다는 점에서 *캐싱 기능이 용량과 성능면에서 이점이 있음
- 응답시간이 빨라지고 트랜잭션이 발생하지 않아 대용량 요청을 효율적으로 처리함

* 캐시 : 자주 사용하는 문서의 사본을 자동으로 보관하여 웹 요청이 캐시에 도착할 때 로컬 사본이 존재하면 문서가 서버쪽이 아닌 캐시로부터 제공됨

Layered System
- 클라이언트와 서버가 분리되어 중간에 프록시 서버, 로드 밸런싱, 암호화 계층 등 중간매체를 사용해 자유도를 높일 수 있음
- 클라이언트는 API만 호출하므로 직접 통신하는 것 인지 중간 서버와 통신하는지 알 수 없음

Self-Descriptiveness
- JSON형태의 메시지를 통해 내용을 직관적으로 이해할 수 있음
- Rest API 메시지 만으로 그 요청이 어떤 행위인지 알 수 있는 자체 표현 구조로 되어있음

 

REST API

- REST의 특징을 기반으로 API를 제공하는 것

- 공공데이터, 구글 맵, 마이크로 서비스 등 대부분이 REST API를 통해 제공함
- HTTP 표준을 기반으로 구현하기 때문에 HTTP를 지원하는 프로그램 언어를 사용하여 클라이언트와 서버를 구현할 수 있음

 

RESTful API

- REST의 6가지 규칙을 잘 지켜서 설계된 API

설계 시 주의사항(경로 네이밍 규칙)

- URI는 정보의 자원을 표현하며, 리소스명은 동사가 아닌 명사를 사용함

  [GET] .../first-user/ (x)   .../user/1 (o)
- 자원의 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
- 슬래시(/)는 계층 관계를 나타낼 때 사용함
- 소문자를 사용함
- 밑줄(_)은 사용하지 않고 하이픈(-)을 사용함

- 확장자(.txt, .png 등)를 사용하지 않음
- URI의 마지막에 슬래시(/)를 포함하지 않음

 

한계점 및 해결방안

한계점

- 클라이언트가 DELETE, PUT 을 사용할 수 없는 경우가 있음

  ˙ HTTP 클라이언트 모듈이 지원하지 않는 경우

  ˙ 방화벽의 정책 문제로 사용할 수 없는 경우

 

해결방안

- 경로 끝에 동사를 추가함

  ˙ POST api.mightyotter.com/otters/2 --> api.mightyotter.com/otters/2/delete

- Request의 Body 안에 데이터의 추가, 삭제, 변경을 구분할 수 있는 인자를 포함시킴

 

예)

-------------- Request -----------------
POST api.mightyotter.com/otters HTTP/1.1
----------------------------------------

-------------- Request -----------------
POST api.mightyotter.com/otters HTTP/1.1
status="DELETE"
----------------------------------------

 

 

 

출처

https://jy-tblog.tistory.com/24

https://www.youtube.com/watch?v=iOueE9AXDQQ