결론 : RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API
즉, REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭한다.
"REpresentational State Transfer"
자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태를 주고 받는 모든 것
즉, 자원(resource)의 표현(representation)에 의한 상태 전달을 뜻합니다.
해당 소프트웨어가 관리하는 모든 것 ( 문서, 그림, 데이터, 해당 소프트웨어 자체 등 )
그 자원을 표현하기 위한 이름
DB의 학생 정보가 자원이면, 'students'를 자원의 표현으로 정함
데이터가 요청되는 시점에 자원의 상태를 전달한다.
JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적
✔️ URI가 URL보다 포괄적인 범위라고 할 수 있다.
모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI
Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
HTTP 프로토콜의 Method를 사용한다.
HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공한다. ( CRUD )
Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있다.
JSON, XML을 통해 데이터를 주고 받는 것이 일반적이다.
REST의 특징을 기반으로 서비스 API를 구현한 것
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것
URI는 명사를 사용한다.(리소스명은 동사가 아닌 명사를 사용해야 한다.)
1-1. 아래와 같은 동사를 사용하지 말 것
/getAllUsers
/getUserById
/createNewUser
슬래시( / )로 계층 관계를 표현한다.
밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용한다.
URI는 소문자로만 구성한다.
HTTP 응답 상태 코드 사용
Ex) https://velog.io/@yellowbutter0327/restapi/220/photo.jpg (X)
RESTful하게 만든 API는 요청을 보내는 주소만으로도 어떤 것을 요청 하는지 파악이 가능하다.
예를들어, https://school.com/grade 의 주소는 학교의 학년들을 목록으로 받는 요청일 것이다.
{
"results" : [
{"idx": 1, "name": "1학년"},
{"idx": 2, "name": "2학년"},
{"idx": 3, "name": "3학년"}
]
}
https://school.com/grade/2 이렇게 idx, 고유번호가 붙는다면, idx가 2인 학년의 정보가 올 것이다.
그리고 https://school.com/grade/2/students 의 students가 붙으면 2반 학생들의 정보를 받아올 수 있다.