Representational State Transfer
REST는 애플리케이션의 아키텍쳐이다. REST는 개발자에게 비교적 높은 수준의 유연성과 자유를 제공한다. 아키텍쳐는 다양한 영역의 의사결정이 모여 만들어진 원칙이다. 아키텍처는 어떠한 작업을 시작할 때 표준으로 잡고 시작을 하나 이는 제한이 아니며 이는 애플리케이션을 제작함에 있어서 기반을 다져주는 역할로써 존재한다.
REST API는 REST 아키텍처 스타일 디자인 원칙을 준수하는 API를 뜻한다. 다른 말로는 RESTful 하다라고 표현하기도 한다.REST API는 CRUD 기능을 수행한다.
Create, Read, Update, Delete 작성하고 읽고 업데이트하고 삭제할 수 있어야 한다. REST API는 GET 요청을 통해 레코드를 검색하고, POST 요청을 사용하여 레코드를 작성하며, DELETE 요청을 사용해 레코드를 삭제한다.REST API는 자원(resource), 행위(verb), 표현(representation)의 3 가지 요소로 구성이 되어 있다.
| 구성요소 | 내용 | 표현 방법 | | -------------- | -------------------------------- | ---------------- | | Resource | 자원 | URl(엔드 포인트) | | Verb | 자원에 대한 행위 | HTTP 요청 메소드 | | Representation | 자원에 대한 행위의 구체적인 내용 | 페이로드 |
REST API에서 클라이언트가 전송하는 리소스 상태에 대한 표현은 HTTP: JSON(Javascript Object Notation), HTML, XLT, Python, PHP, String의 형식으로 전송이 되어야 한다.
REST API 6가지 디자인 원칙
1.균일한 인터페이스로 구성할 것
요청이 어디에서 오는지와는 무관하게 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 한다. 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각은 하나의 URI(Uniform Resource Identifier)에 속하게끔 보장해주어야 한다.
- 리소스를 표현함에 있어서 리소스의 이름은 동사보다 명사를 사용해야 한다. ex) 🚫 GET/getTodos/1, 🚫 GET/todo/show/1 ✅ GET/todos/1
2.클라이언트-서버 디커플링
REST API 디자인에서 클라이언트와 서버는 완전히 독립적이어야 한다는 뜻이다. 클라이언트 애플리케이션이 알아야할 유일한 정보는 요청된 리소스의 URI이며 HTTP 요청을 통한 상호작용이외에 다른 방법으로 서버 애플리케이션과 상호작용을 해서는 안된다. 또한 서버 애플리케이션은 HTTP를 통해 요청된 데이터를 전달하는 것 이외에 클라이언트 애플리케이션을 수정해서는 안된다.
- HTTP 요청 메소드
| HTTP 요청 메소드 | 목적 | 페이로드 (사용에 있어 전송되는 데이터) | | ---------------- | -------------------------------------------- | ------------------------------------------------------------------------------------- | | GET | 모든 특정 리소스를 취득하는 용도로 사용된다. | 전송되지 않음 (사용자가 원하는 데이터를 특정하지 않고 신경쓰지 않고 전체를 전달한다.) | | POST | 리소스를 생성하는 것에 사용된다. | 전송됨 (사용자가 원하는 특정 데이터를 특정하고 그 데이터를 제공한다.) | | PUT | 리소스 전체를 교체할 때 사용된다 | 전송됨 | | PATCH | 리소스의 일부 내용을 수정할 때 사용된다. | 전송됨 | | DELETE | 모든 / 특정 리로스를 삭제할 때 사용된다. | 전송되지 않음 |
3.Stateless
클라이언트 애플리케이션에서 요청을 서버 애플리케이션에서 처리할 때 필요한 모든 정보를 포함해야 한다는 것을 의미한다. 클라이언트의 요청과 관련된 데이터를 서버 애플리케이션은 저장하지 않아야 한다. 이에 대한 예시는 인터넷 검색 기능이 있다. 인터넷 검색 창에 우리가 검색한 내용에 대해서 검색을 하지 않고 지우더라도 그 데이터는 남아 있지 않다.
- 네트워크 프로토콜
네트워크 프로토콜은 서로 다른 시스템 및 기기 간 데이터 교환을 원활히 하기 위한 표준화된 통신 규약이다. 프로토콜 계층적인 구조로 정의되어 있고 각 계층별 역할이 구분된다. 이러한 프로토콜은 사용자 별로 다른 환경에서 통신을 주고 받을 때 서로 충돌 및 지연을 방지하기 위하여 등장하였다.
4.캐싱 가능성
가급적이면, 리소스를 클라이언트 또는 서버 측에서 캐싱할 수 있어야 한다. 또한 서버 응답 전에는 전달된 리소스에 대한 캐싱이 허용되는 지의 여부가 포함되어 있어야 한다. 이에 대한 목적은 서버측의 확정성 증가와 함께 성능 향상을 얻기 위함이다.
- 캐싱
캐싱이란 일시적인 특징이 있는 데이터 하위 집합을 저장하는 고속 데이터 스토리지 계층을 뜻한다. 캐싱을 한다는 것은 클라이언트에서 주는 데이터를 서버 쪽에 빠르게 요청을 처리하기 위하여 데이터를 효율적으로 계층화하여 정리한다는 것을 뜻한다.
5.계층 구조 아키텍처
REST API에서는 호출과 응답이 서로 다른 계층을 통과한다. 클라이언트 애플리케이션과 서버 애플리케이션은 연결된 것 처럼 보이지만 그렇지 않다 그 사이에 중계기가 있을 수도 있다. 하지만 이러한 사실을 클라이언트나 서버가 누구와 통신하는지에 대한 여부를 클라이언트나 서버 둘다 알 수 없게끔 설계되어야 한다.
6.코드 온디맨드
REST API는 일반적으로 정적 리소스를 전송한다. 하지만 특정 경우에는 실행 코드를 포함할 수 있어야 한다. 이러한 실행 코드를 통해 클라이언트의 기능을 확장할 수 있어야 한다.