REST 아키텍처, RESTful API란

1. REST

REST (Representational State Transfer)
웹 상의 서버와 클라이언트 간 통신을 위한 아키텍처

 

등장 배경

1. 사용자 인터렉션의 증가 (정적 웹 -> 동적 웹)
초기에는 정적웹이 대다수였지만 시간이 지나면서 인터렉션으 증가하고 동적웹이 많아졌다.
따라서 API 호출의 빈도도 많아졌으며, 이에 따른 아키텍처의 필요성이 높아졌다.

2. 데이터 양 증가
데이터의 양이 증가하면서 동적으로 데이터베이스에 접근하여 데이터를 사용하게 되면서, 통신을 위한 아키텍처의 필요성이 높아졌다.

3. 다양한 기기(스마트폰, 태블릿 등)의 등장
스마트폰과 태블릿과 같은 여러 기기들이 등장하면서, 브라우저 웹 뿐 아니라 다양한 기기에서 공통적으로 사용할 수 있는 통신 아키텍처가 필요하였다.

4. 개발자 편의
개발을 진행하면서 웹-서버간 통신을 보다 체계적으로 개발 할 필요가 있었다.

 

REST의 주요 원칙

1. 리소스 식별
고유한 URL을 통해 모든 자원이 식별 되어야 한다. 즉, URL을 통해 모든 자원을 파악할 수 있다는 것이다.
다음 URL을 분석해보자
https://api.example.com/users/1
- "http://api.example.com" 을  통해 시스템에 접근한다.  
- user id가 1인 데이터에 접근한다.
이처럼 url을 통해 사용자는 직관적으로 자원을 식별할 수 있어야한다.

2. 무상태성 (statelessness)
서버는 클라이언트는 서로의 상태를 알 수 없다. 따라서 요청을 처리할 충분한 정보를 포함해야한다.
만약 로그인 상태를 체크하여 로그인 된 유저에게만 api 접근을 허용하려고한다.
이 때 서버에서는 클라이언트에서 로그인이 되었는지 알 수 없기 때문에 토큰 정보를 같이 보낸다.

3. 자원의 조작 (Representation)
JSON이나 XML 등의 형식으로 요청과 응답이 처리되며, 이 때 전송 받은 데이터는 가공하여 사용 가능하다.

4. 모든 내용을 담아야 한다.
요청과 응답 시 전송하는 메시지를 통해 모든 처리가 가능해야한다.

5. 추가적인 상태 변화를 위한 정보를 공유한다. (HATEOAS, 선택적 사용)
서버를 통한 응답을 통해 이후 가능한 행동에 대한 하이퍼링크를 포함해야한다.
이 말의 뜻은 사용자 정보를 조회하는 GET 요청을 서버에 전송하였을 때, 서버로부터 받는 응답에는 사용자를 수정하거나 삭제할 수 있는 URL, method를 포함된다는 것이다. 해당 특징은 선택적 사용된다.

6. 캐시 가능 여부 포함
응답을 통해 해당 정보가 캐시 가능 여부와 가능 시 유지 기간을 포함해야한다.

 

---

2. REST API

REST API: REST의 원리를 따르는 API

 

설계 규칙 (컨벤션)

1. URL에는 동사보다는 명사를 사용하며, 대문자보다 소문자를 사용한다
2. 마지막 슬래시를 제외한다.
3. 언더바가 아닌 하이폰을 사용한다.
4. 확장자를 포함하지 않는다.
5. 행위를 포함하지 않는다.

 

사용 메서드

HTTP 메서드를 통해서 REST API를 사용할 수 있다.이 떄 각 메서드는 CRUD (Create, Read, Update, Delete)기능을 수행한다.

1. Create - POST
리소스 내 레코드를 생성

2. Read - GET
리소스 내 레코드를 검색

3. Update - PUT, PATCH
리소스 내 레코드를 업데이트한다.
  * PUT: 부분 업데이트
  * PATCH: 전체 업데이트

4. Delete - DELETE
리소스 내 레코드를 삭제한다.