RESTful?
REST API는 RESTful한 API를 뜻한다.
RESTful은 일련의 특징과 규칙 등을 지키는 것을 말한다.
2000년에 Roy Thomas Fielding이 쓴 논문에서 처음 등장했다고 한다.
특징
- Uniform-Interface
- API에서 자원들은 각각의 독립적인 인터페이스를 가지며 각각의 자원들이 url 자원식별, 표현을 통한 자원조작, Self-descriptive messages, HATEOAS 구조를 가지는 것을 뜻한다.
- 예를 들어 HTTP1 → 1.1 → 2.0 → 3.0 으로 기술이 발전했다고 해서 어떤 웹사이트가 동작하지 않는 일이 일어나지 않는다는 것이 독립적인 인터페이스를 가진다고 볼 수 있다.
- url 자원 식별
- 자원은 url로 식별되어야 한다.
- 표현을 통한 자원조작
- url과 GET, DELETE 등 HTTP 표준메서드 등을 통해 자원을 조회, 삭제 등 작업을 설명할 수 있는 정보가 담겨야 한다는 뜻.
- Self-descriptive messages
- HTTP Header에 타입을 명시하고 각 메시지들은 MIME types에 맞춰 표현되어야 한다.
- 예를들어 .json을 반환한다면 application/json이라고 명시해주는 것.
- MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준이다.
- HATEOAS 구조
- Hypermedia as the Engine of Application State
- 하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해주어야 한다는 뜻.
- 보통 href, links, link, url 속성 중 하나에 해당 데이터의 URL을 담아서 표기해야 한다.
- Stateless
- HTTP 자체가 Stateless이기 때문에 HTTP를 이용하는 것 만으로도 충족된다.
- Cacheable
- HTTP는 기본적으로 캐싱이 된다.
- GET 메서드에 한정해서 캐싱이 되며
Cache-Control:max-age=100이런식으로 한정된 시간을 정할 수 있다. - GET 응답 이후에 새로고침을 하면 304 상태코드를 볼 수 있고 원래 있던 js, css 이미지 등을 불러온다.
- 캐싱된 데이터가 유효한지 판단하기 위해 Last-modified, Etag라는 헤더값을 쓴다. Etag는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것이다.
- Client-Server 구조
- 클라이언트와 서버가 서로 독립적인 구조를 가져야 한다.
- 서버는 그저 API를 제공하고 클라이언트는 HTTP로 받는 로직만 잘 처리하면 된다는 뜻이다.
- Layered System
- 웹 기반 서비스를 하면 계층구조로 나눠져 있는 아키텍쳐가 된다.
REST API의 URI 규칙
- 동작은 HTTP 메서드로만 해야 하고 url에 해당 내용이 들어가면 안된다.
- GET, PUT, PATCH, DELETE 등을 쓸 때 예를 들어 DELETE를 쓴다고 하면 /user/delete/1 이런식으로 쓰면 안된다는 것이다.
- .jpg, .png 등 확장자 표시는 하면 안 된다.
- 동사가 아닌 명사로만 표기해야 한다. 예를 들어 유저가 소유한 책을 조회한다고 하면 /user/{userid}/books 이런식으로 해야 한다.
- 계층적인 내용을 담고 있어야 한다. /user/major/level 처럼 계층이 있어야 한다.
- 대문자가 아닌 소문자로만 쓰며 너무 길 경우에는 언더바(_)가 아니라 바(-)를 써야 한다.
- HTTP 응답 상태코드를 적재적소에 활용해야 한다.