REST란?

"REST"의 개념

GET /movies(Get list of movies)
GET /movies/:id (Find a movie by its ID
POST /movies (Create a new movie)
PUT /movies (Update an existing movie)
DELETE /movies (Delete an existing movie)

REST의 정의

• Representational State Transfer의 약자
• 자원(Resource): URI
• 행위(Verb): HTTP Method
• 표현(Representations)

• 자원을 이름(자원의 표현)으로 구분하여 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
→ 자원(resource)의 표현(representation)에 의한 상태 전달
→ 자원(resource)의 표현에서 "자원"은 해당 소프트웨어가 관리하는 모든 것
ex) 문서, 그림, 데이터 해당 소프트웨어 자체 등
→ "자원의 표현"은 해당 자원을 표기하기 위한 이름
ex) DB의 학생 정보가 "자원(resource)"일때, "students"를 자원의 표현으로 정함

• 상태(정보) 전달
→ 데이터의 정보가 요청되어지는 시점에서 자원의 상태(정보)를 전달
→JSON 혹은 XML을 통해 데이터를 주고 받는게 일반적!

• World Wide Web(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
• REST는 기본적으로 웹의 기존 기술 + HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
• REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나

❈ 프로토콜:
• 컴퓨터 내부에서, 혹은 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙체계
• 기기간 통신은 교환 되는 데이터의 형식에 대해 상호 합의를 요구함
→ 그래서 이런 형식을 정의하는 규칙의 집합을 프로토콜 이라고 함

❈ HTTP:
• HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜
• HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트 - 서버 프로토콜이기도 함
• 라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미
•하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성 됨

REST의 구체적인 개념

•HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP METHOD(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
• REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고, HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처
•웹 사이트의 이미지, 텍스트, DB내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여

❈ HTTP Method: REST를 지키면서 행위를 전달하는 방법

❈ 보통 CRUD에서 다음과 같이 사용
• Create: 생성(Post)
• Read: 조회(GET)
• Update: 수정(PUT)
• Delete: 삭제(Delete)

❈ 전체 종류
• GET: 서버로 부터 데이터를 취득
• POST: 서버에 데이터를 추가, 작성 등
• PUT: 서버의 데이터를 갱신, 작성 등(지정한 데이터를 전부 수정, 멱등)
• DELETE: 서버의 데이터를 삭제
• HEAD: 서버 리로스의 헤더(메타 데이터의 취득) / header의 정보 조회
• OPTIONS: 리소스가 지원하고 있는 메소드의 취득
• PATCH: 리소스의 일부분을 수정(정보의 일부분 변경, 멱등하다고 볼 수 없음)
• CONNECT: 프록시 동작의 터널 접속을 변경

REST의 장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없음
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 함
• HTTP 프로토콜에 따르는 모든 플랫폼에서 사용가능
• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장
• REST API 메시자가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악가능
• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화 함
• 서버와 클라이언트의 역할을 명확하게 분리 함

REST의 단점

• 표준이 존재 ❌
• 사용가능한 Method가 4가지 밖에 없음(HTTP Method 형태가 제한적임)
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URI보다 Header 값이 더 어렵게 느껴짐
•구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 있음
• PUT, DELETE를 사용 못함
• pushState를 지원하지 않음

REST가 필요한 이유

• 에플리케이션 분리 및 통합
• 다양한 클라이언트의 등장
• 최근 서버 프로그램은 다양한 브라우저와 안드로이드혼, 아이폰과 같은 모바일 디바이스에도 통신할 수 있어야 함

출처: https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html