REST API

REpresentational State Transfer

• 자원의 표현으로 구분하여 해당 자원의 상태를 주고받는 모든 것

REST 구성요소

• 자원 : URI(Uniform Resource Identifier)
• 행위 : HTTP Method(GET, POST, PUT, DELETE 등..)
• 표현 : JSON, XML, TEXT, RSS

참고 URI

URL (Uniformed Resource Locator)

• 프로토콜 포함
• 해당 자원의 위치, Path를 의미
• 일반적으로 사이트 도메인을 자주 의미함.
• 웹 상 뿐만 아니라 컴퓨터 네트워크상의 자원은 모두 나타낼 수 있다.

URN (Uniformed Resource Name)

• 프로토콜 포함 X
• 해당 자원의 이름을 의미
• 독립적인 자원 지시자
• Page 이후 부분까지 포함

출처: https://programming119.tistory.com/194 [개발자 아저씨들 힘을모아]

REST 특징

• 서버(자원이 있는 곳) - 클라이언트(자원을 요청) 구조
  • 서버 : API 제공, 요청을 처리, 저장을 수행
  • 클라이언트 : 사용자 인증 또는 세션등을 관리 및 처리
• 무상태성, 캐싱 가능
  • HTTP가 무상태 프로토콜이므로, REST API도 무상태성을 지님
  • 무상태성이란?
    • HTTP는 이전의 정보나 현재 통신의 상태가 남아 있지 않는다.
    • 따라서 자원의 낭비를 줄일 수 있지만, 클라이언트의 상태를 유지시켜 줄 수 없습니다.
    • 그렇기에 쿠키나 세션 같은 것들로 클라이언트의 상태를 유지시켜 주는데, 만약 쿠키나 세션이 없다면 우리는 새로고침을 할 때마다 로그인을 해야 되는 대참사가 발생한다.
  • 캐싱을 통해 대량의 정보를 효율적으로 처리할 수 있다.
  • 캐싱 사용으로 응답시간이 짧아지고, 서버 트랜잭션이 발생하지 않기 때문에 전체적인 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있음

REST 장점

• 인프라 구축 비용 감소
  • HTTP에 있는 인프라를 그대로 사용할 수 있음
  • API를 위한 별도의 인프라 구축을 할 필요가 없음
• 플랫폼 범용성
  • HTTP 표준을 따라가기 때문에, 그에 기반한 장점들을 가져갈 수 있음
  • 해당 프로토콜을 사용하는 모든 플랫폼에서 사용이 가능함
• 문제의 최소화
  • API가 의도하는 바를 쉽게 요청할 수 있음
  • 여러가지 문제점을 최소화 가능

REST 단점

• 사용할 수 있는 method 제한(4가지)
• 구형 브라우저 미 지원
• 표준의 미존재

REST API

• REST를 기반으로 서비스 API를 구현한 것

REST API 설계 규칙

• 리소스의 종류

  • 리소스는 동사보다 명사, 대문자보다 소문자를 사용한다.

• 도큐먼트

  • 도큐먼트 이름은 단수를 사용한다.

• 컬렉션

  • 컬렉션은 복수를 사용한다.

• 스토어

  • 스토어는 복수를 사용한다.

• 자원의 행위는 HTTP Method로 표현한다.

• URI에는 메소드가 들어가면 안된다.(ex-example/delete/1)

• 행위에 대한 동사가 들어가면 안된다.

• 경로 중 변화값은 유일한 값을 사용한다.

• 슬래시 구분자를 사용한다.

• 마지막 문자로 슬래시를 포함하지 않는다. (ex - example/)

• URI에 밑줄은 사용하지 않는다.

• 파일 확장자는 URI에 포함하지 않는다. (ex - example.png)

RESTFul

• 위와 같은 규칙들을 잘 따른 것(REST API를 REST 답게 쓰는 것)
• REST 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용하는 용어
• REST API로 제공되는 웹 서비스를 RESTFul하다고 할 수 있음.
• 이해하기 쉽고 사용하기 쉬운 API를 만드는 것이 목표
• 성능이 중요한 목표가 아님

REST를 사용해야 하는 이유

• RESTFul 서비스라면 데이터만 주고 받기 때문에 다른 모듈과, 혹은 애플리케이션과 해당 API를 통해 상호 통신을 할 수 있고, 멀티 플랫폼에 대한 지원을 하는 서비스이기 때문에 유용하다.