REST
REST는 자원을 이름으로 구분해서 자원의 상태를 주고 받는 것을 의미한다. REST의 구성 요소는 Resource(자원), Verb(행위), Representation of Resource(표현)이 있다.
Resource
모든 자원에는 고유한 id가 존재하고, 자원은 서버에 존재한다. Client는 URI를 이용해서 자원을 지정하고, 자원의 상태(정보)에 대한 동작을 서버에 요청하게 된다.
Verb
HTTP 프로토콜의 메소드를 사용한다. HTTP 프로토콜의 메소드는 GET, POST, PUT, PATCH, DELETE가 있다. 모두 client에서 서버로 요청할 때 사용된다.
| METHOD | DETAIL |
|---|---|
| GET | URI가 가진 정보 조회를 요청한다. |
| POST | client에서 서버로 정보를 전송한다. |
| PUT | client에서 정보 수정을 요청한다. |
| PATCH | PUT과 동일하게 정보 수정을 요청한다. |
| DELETE | 정보 삭제를 요청한다 |
Representation of Resource
client와 server가 데이터를 주고받는 형태로 json, xml 형식을 많이 사용한다고 한다.
RESTful API
RESTful은 Representational State Transfer의 약자로 소프트웨어 아키텍처의 한 형식이다. 네트워크 아키텍처 원리는 자원을 정의하고 자원에 대한 주소를 지정하는 방법이라고 한다. API가 RESTful의 조건을 만족하기 위해서는 6가지 조건이 있다.
cliient-server architecture
자원(정보)를 가지고 있는 부분이 server이고, 자원을 요청하는 부분이 client이다. server는 API 제공, 비즈니스 로직을 처리하고, client는 사용자 인증이나 세션, 로그인 정보 등을 직접 관리하고 책임진다. server와 client 사이의 의존성이 줄어들게 된다.
stateless
stateless(무상태) 특징은 HTTP의 특성을 이용하기 때문이다. 서버에서 작업을 하기 위해 상태 정보를 기억할 필요가 없고 client의 요청에 대해서만 처리해 주면 되기 때문에 단순한 구현이 가능해진다. server는 client의 요청을 독립적으로 인식하고 처리하기 때문에 server 처리의 일관성을 부여하고 부담이 줄어들게 된다.
cashable
cashable(캐시 처리 가능) 특징은 HTTP의 특징인 캐싱 기능을 사용할 수 있다. 대량의 요청을 효율적으로 관리 가능하며, 캐시 사용으로 응답 시간이 빨라진다.
layered system
layered system(계층화) 특징은 client와 server의 통신 사이에 프록시 서버나 암호화 계층 등 중간 매체를 둘 수 있다. 또한 중간 매체와 통신 여부를 client나 server는 알 수 없도록 설계 되어야 한다.
uniform interface
uniform interface(인터페이스 일관성) 특징은 URI로 지정한 resource에 대한 동작이 통일되어야 하고, 사용자의 정보가 하나의 URI에 속함을 보장해야 한다. 특정 언어나 기술에 종속적이지 않고 HTTP 프로토콜을 따르는 플랫폼에서 모두 사용 가능하다.
code on demand(optional)
REST API는 일반적으로 static resource를 전송하지만, 응답에 실행 코드가 포함될 수 있다. 이러한 경우 코드는 요청 시에만 실행되어야 한다.
REST API 설계
REST를 만족하는 API를 설계하기 위해서는 세부적인 규칙이 필요하다.
http://example.com/post (O)
http://example.com/post/ (X)- URI는 명사를 사용하고 소문자로 작성되어야 한다.
- URI의 마지막에는
/를 포함하지 않는다.
http://example.com/post-list (O)
http://example.com/post_list (X)- URI에는 언더바가 아닌 하이픈을 사용한다.
http://example.com/post/assets/example (O)
http://example.com/post/assets/example.png (X)- URI에는 파일의 확장자를 표시하지 않는다.
http://example.com/post/:post-id
http://example.com/post/{post-id} (O)- resource 간에 연관 관계가 있는경우 위와 같이 사용한다.
path parameter와 query string
프로젝트를 진행하면서 게시글이나 사용자 정보에 대한 상세 페이지로 넘어갈 때 path parameter를 사용했다. Path parameter는 /post/:postId로 라우팅이 되고 백엔드에서는 req.params.postId로 받아와 사용한다.
이번 프로젝트를 진행하면서 조건에 따라 조회되는 결과가 다르게 나오는 동작을 구현해야 했는데, query string방식을 몰라서 body로 넘겨서 값을 받았다. 코치님이 Query string을 사용하는게 좋을것 같다고 하셔서 바로 적용해 보았다. Path parameter와 query string의 차이를 알아보자.
Path parameter
Path parameter는 client 에서 request에 값을 붙여서 요청하는 방식이다. 예를 들어 게시글의 ID가 expost1이라고 할 때 해당 게시글을 클릭하면 라우팅되는 URI는 /post/expost1이 된다. 백엔드에서는 req.params.postId로 받아서 ID를 가지고 데이터 베이스에 요청하여 게시글을 찾게 된다.
이렇게 단일 데이터를 찾는 경우 path parameter를 사용하게되면 REST API의 조건에 맞는 resource의 연관 관계를 보여줄 수 있다.
Query string
이번 프로젝트에서 query string을 사용한 부분은 pagination과 게시글을 찾는 조건을 붙이기 위해 사용했다. 프론트에서 axios get요청으로 endpoint와 params에 필요한 정보를 붙여 요청을 하게되고, 백에서는 req.query로 정보를 받아온다.
프론트에서 query string으로 요청하게 되면 URI는 /post?category=player&val1=5와 같이 된다. 게시글이 많아 pagination을 해야하는데 query 정보에 현재 페이지와 한 페이지에 몇개를 보여주고 싶은지(perPage)를 넘겨주면 게시글 조건 검색과 페이징이 동시에 가능하다.
Query string은 정보 검색, 정렬, 필터링 등의 동작에 사용되면 좋을것 같다는 생각이 들었다.