REST(REPesentational State Transfer)
웹이 HTTP를 제대로 사용하지 못하고 있음을 인지하고 HTTP의 장점을 최대한 활용할 수 있는 아키텍처로 REST를 도입하여 의도에 맞게 HTTP 프로토콜을 설계하게 됨
RESTful: REST의 기본 원칙을 준수하는 서비스 설계
REST: 클라이언트가 HTTP를 기반으로 서버의 리소스에 액세스하는 방법을 규제하는 아키텍처입니다.
REST API: 서비스 API가 REST 기반으로 구현됨을 의미
REST API 구성
REST는 고유한 표현 구조로 구성되어 있으므로 HTTP 요청의 내용은 REST API에서만 이해할 수 있습니다.
| 요소 | 세부 사항 | 표현 방법 |
| 지원(자원) | 자원 | URI(엔드포인트) |
| 동작(동사) | 자원에 대한 행동 | HTTP 요청 방법 |
| 표현 | 자원에 대한 조치 세부사항 | 유효 탑재량 |
REST API 설계 원칙
1. URI는 리소스를 나타내야 합니다.
URI는 리소스를 나타내는 데 중점을 두어야 합니다. 리소스를 식별하는 이름은 동사가 아닌 명사를 사용해야 합니다!
2. 리소스에 대한 동작은 HTTP 요청 메서드를 통해 표현됩니다.
HTTP 요청 방법은 클라이언트가 요청의 유형과 목적을 서버에 알리는 방법입니다(리소스에 대한 작업).
CRUD는 주로 5가지 요청 방식(GET, POST, PUT, PATCH, DELETE 등)을 사용하여 구현됩니다.
| HTTP 요청 방법 | 유형 | 목적 | 유효 탑재량 |
| 얻다 | 색인/검색 | 모든/특정 리소스 획득 | 엑스 |
| 우편 | 만들다 | 리소스 생성 | 영형 |
| 놓다 | 바꾸다 | 자원의 완전한 교체 | 영형 |
| 반점 | 수정하다 | 리소스의 일부 수정 | 영형 |
| 삭제 | 삭제 | 모든/특정 리소스 삭제 | 엑스 |
리소스에 대한 액션은 URI로 표현되지 않고 HTTP 요청 방식으로 표현됩니다.
페이로드: 사용 중 전송되는 데이터. 페이로드는 데이터와 함께 전송되는 헤더, 메타데이터 등의 부분을 제외한 전송의 근본적인 목적인 데이터의 일부! 컴퓨터 보안에서 페이로드는 맬웨어입니다!