yeoseon / tip-archive

트러블 슈팅 및 팁을 모아두는 레포 (Today I Learned)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

REST, RESTful API

yeoseon opened this issue · comments

REST(Representational State Transfer)

개요

Resource Oriented Architecture

자원(Resource)을 중심으로 HTTP Method를 통해 자원(Resource)를 처리하도록 설계하는 것.

HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

Pros and Cons

Pros

  • HTTP 프로토콜의 인프라를 그대로 사용하므로, 별도의 인프라 구축이 필요 없다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
  • REST API 메시지가 의도하는 바를 명확하게 파악할 수 있다.
  • 서버와 클라이언트 역할을 명확하게 분리한다.

Cons

  • 표준이 존재하지 않는다.
  • 사용할 수 있는 메소드가 4가지 밖에 없다.
  • URL보다 Header 값이 더 어렵게 느껴지는 경우가 있다. (브라우저를 통해 테스트 할 일이 많을 경우)
  • 구형 브라우저가 지원해주지 못하는 부분이 존재한다. (PUT, DELETE, pushState)

REST 구성

  • 자원(RESOURCE) - URI
  • 행위(Verb) - HTTP METHOD
  • 표현(Representations)

REST API 설계 규칙

  1. URI는 정보의 자원을 표현해야 한다.
  • 리소스명은 동사보다는 명사를 사용한다.

예) show 라는 의미는 GET을 통해 충분히 표현할 수 있다.

GET /users/show/1 (X)
GET /users/1 (O)
  1. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
GET /members/delete/1 (X)
DELETE /members/1 (O)

RESTful API

REST 설계 규칙을 잘 지켜 만들어진 API를 RESTful한 API 라고 말한다.

RESTful 하게 API를 설계한다는 것

  1. 리소스 와 행위 를 명시적이고 직관적으로 분리한다.
  • 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 한다.
  • 행위는 HTTP Method로 표현하고, GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제)을 분명한 목적으로 사용한다.
  1. Message 는 Header 와 Body 를 명확하게 분리해서 사용한다.
  • Entity 에 대한 내용은 body 에 담는다.
  • 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header 에 담는다.
  • header 와 body 는 http header 와 http body 로 나눌 수도 있고, http body 에 들어가는 json 구조로 분리할 수도 있다.
  1. API 버전을 관리한다.
  • 환경은 항상 변하기 때문에 API 의 signature 가 변경될 수도 있음에 유의하자.
  • 특정 API 를 변경할 때는 반드시 하위호환성을 보장해야 한다.
  1. 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
  • 브라우저는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json 으로 보내든, 둘 다 form-data 형식으로 보내든 하나로 통일한다.
  • 다른 말로 표현하자면 URI 가 플랫폼 중립적이어야 한다.

Ajax와 REST

빠른 속도의 웹서비스 구현을 위해 Ajax 통신으로 구동되도록 개발하는 일이 많다.
Ajax를 이용하면 중복 콘텐츠를 여러 번 전달하지 않아도 되고, 브라우저 렌더링 과정이 간소화 되어 빠르게 구축할수 있다.

하지만 URL과 관련된 문제가 있다. 콘텐츠가 바뀌어도 URL은 그대로이기 때문에, 내가 보던 정보를 친구에게 전송하면 친구는 볼 수 없는 예시가 바로 그것이다.
이것은 REST 에서 2가지 방식으로 보완했다.

  1. #! 기법
  • Ajax통신을 통해 이동되는 페이지의 URI 는 현재 URI의 #! 이후에 붙인다.
  • 페이지가 처음 열릴 때, #! 이후로 URL가 붙어있다면 해당 URI로 redirect를 해준다.
  • URI가 지저분해진다.
  1. pushState 라는 새로운 표준 이용하기
  • JavaScript의 pushState를 통해 Ajax 통신 후에 변경된 컨텐츠의 URI를 제대로 바꿔줄 수 있다.
  • 구형 브라우저에서는 동작하지 않아서 하위 호환에 신경을 써야 한다.

Reference