REST란?
REST (Representational State Transfer)
-
HTTP 프로토콜로 데이터를 전달하는 프레임워크이다.
-
자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는다.
-
클라이언트와 서버 간의 구성요소를 엄격히 분리하여 구현은 단순화하고 확장성과 성능을 높일 수 있다.
-
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
-
자원 기반의 구조(ROA, Resource Oriented Architecture) 설계에 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐이다.
어떻게 작동할까?
클라이언트는 리소스가 필요할 때 API를 이용해 서버에 접속한다.
- 클라이언트가 서버에 요청한다.
- 서버가 클라이언트를 인증하고 요청을 수행할 권한이 클라이언트에게 있는지 확인한다.
- 서버가 요청을 수신하고 처리한다.
- 서버가 클라이언트에게 응답을 반환한다. 응답에는 요청 성공여부와 클라이언트가 요청한 정보가 포함된다.
요청에 필요한 것은?
Methods
-
GET
- 자원을 받아오기만 할 때 사용한다.
- 어떠한 방식으로도 자원의 상태를 변경시키지 않는다.
- 멱등성(여러 번 호출해도 동일한 결과를 얻음)을 띈다.
-
POST
- 새로운 자원을 추가할 때 사용한다.
- 비멱등성으로, 동일한 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성한다.
-
PUT
- 존재하는 자원을 변경할 때 사용한다.
- POST는 여러 자원에 수행되는 반면, PUT은 단일 자원에만 수행된다.
- 멱등성으로, 동일한 요청을 여러 번 전송해도 결과는 동일하다.
-
DELETE
- 자원을 삭제할 때 사용한다.
- 서버 상태를 변경하므로 적절한 인증이 없으면 사용할 수 없다.
- 멱등성으로, 자원을 삭제한 후 반복적으로 요청하면 404 코드를 받는다.
-
PATCH
- 한 자원의 데이터를 부분적으로 변경할 때 사용한다.
- PUT은 자원을 완전히 대체하는 경우에 사용하고, PATCH는 존재하는 자원을 부분적으로 업데이트하기 위해 사용한다.
- 모든 브라우저, 서버에서 지원하는 것은 아니다.
이점은?
- HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 별도의 인프라를 구축할 필요가 없다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.
- REST가 클라이언트-서버 상호작용을 최적화하기 때문에 효율적이다.
- 성능을 저하시키는 병목 현상을 일으키지 않으면서 확장성을 지원한다.
- 클라이언트-서버를 완전히 분리한다.
- 각 부분이 독립적으로 발전할 수 있도록 서버 구성요소를 단순화하고 분리한다.
- 서버 애플리케이션의 변경이 클라이언트 애플리케이션에 영향을 주지 않는다.
특징은?
REST API란?
- REST 기반으로 서비스 API를 구현한 것이다.
- 설계 규칙은 다음과 같다.
- '/'는 계층 관계를 나타내는데 사용한다.
- URI 마지막 문자로 '/'를 포함하지 않는다.
- '-'은 URI 가독성을 높이는데 사용한다.
- '_'은 URI에 사용하지 않는다.
- URI 경로는 소문자가 적합하다.
- 파일 확장자는 URI에 포함하지 않는다.
- 행위를 포함하지 않는다.
RESTful이란?
-
REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
- REST 원리를 따르는 시스템은 RESTful하다고 지칭된다.
-
REST의 설계규칙을 올바르게 지키는 REST API를 제공하는 웹 서비스이다.
-
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로 한다.
-
REST를 사용했다고 하여 모두가 RESTful한 것은 아니다.
- CRUD를 모두 POST로만 처리하는 API
- route에 resource 외의 정보가 들어가는 경우 (/updateId)
- RESTful API는 API의 이해도와 호환성을 높이기 위함이기 때문에, 성능을 중요시한다면 반드시 RESTful API를 구현할 필요는 없다.
출처