REST(Representational State Transfer)는 웹을 이용할 때 제약조건들을 정의하는 소프트웨어 아키텍처로 HTTP URL을 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD(Create, Read, Update, Delete)를 적용하는 통신 규약이다.
REST의 특징
Client-Servcer 구조
클라이언트와 서버는 서로 독립적이며, 클라이언트는 URI 리소스만 알아야 한다.
인터페이스의 변경 없이도 서로 독립적으로 개발될 수 있어야 한다.
Stateless(무상태성)
클라이언트의 모든 요청은 해당 요청을 이해할 수 있는 정보를 포함해야 한다.
서버는 어떠한 상태도 저장하지 않으며, 컨텍스트를 유지해야 하는 정보는 클라이언트에 저장되어야 한다.
Cacheable
서버는 Response의 cache-control 헤더를 통해 캐싱 가능 여부를 제공해야 한다.
클라이언트는 캐싱을 통해 서버와 상호작용을 줄이고 성능과 가용성을 개선할 수 있다.
일관된 인터페이스
Identification of resources: URI라는 고유 식별자를 사용하여 자원을 식별한다.
Manipulation of resources through representations: 클라이언트가 자원을 요청할 때 서버는 자원 자체가 아닌 자원의 표현으로 응답한다.
Self-descriptive messages: 메시지는 자신을 어떻게 처리해야 하는지에 대한 정보를 포함해야 한다.
Hypermedia as the engine of application state: 하이퍼 링크에 자신에 대한 상태 정보가 담겨 있어야 한다.
Layered System
REST는 다중 계층 구조를 가질 수 있도록 허용하며, 각 레이어는 자신과 통신하는 컴포넌트 외에는 정보를 얻을 수 없다.
Code on demand
서버는 클라이언트를 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
REST API 설계 예시
소문자 사용: URI는 소문자로 작성한다.
❌ http://develop.tistory.com/users/Post-Comments
⭕ http://develop.tistory.com/users/post-comments
하이픈 사용: 언더바(_) 대신 하이픈(-)을 사용한다.
❌ http://develop.tistory.com/users/post_comments
⭕ http://develop.tistory.com/users/post-comments
마지막 슬래시 제거: URI 마지막에 슬래시(/)를 포함하지 않는다.
❌ http://develop.tistory.com/users/
⭕ http://develop.tistory.com/users
행위는 HTTP Method로 표현: 행위는 URI 대신 Method를 사용하여 전달한다.
❌ POST http://develop.tistory.com/users/post/1
⭕ PUT http://develop.tistory.com/users/1
파일 확장자는 URL에 포함하지 않음: 파일 확장자는 URI에 포함하지 않는다.
❌ http://develop.tistory.com/users/photo.jpg
⭕ GET http://develop.tistory.com/users/photo / HTTP/1.1 Host: develop.tistory.com Accept: image/jpg
명사 사용: 전달하고자 하는 명사를 사용하되, 컨트롤 자원을 의미하는 경우 예외적으로 동사를 사용한다.
