RESTful 하다는 것

REST API

웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이며 이를 잘 지킨 아키텍처를 RESTful하다라고 합니다. 먼저 이 아키텍처는 Uniform-Interface를 갖는 것이 특징입니다.

​

Uniform-Interface

독립적으로 자원들이 각각 인터페이스를 가져야 한다는 것입니다.

- 웹 페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.

- 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.

- HTTP 명세가 변경되어도 웹은 잘 동작한다.

- HTML 명세가 변경되어도 웹은 잘 동작한다.

​

그리고 이 아키텍처의 규칙은 다음과 같습니다.

​

0. Self-descriptive messages

각 자원들의 타입에 대하여 media 타입을 이용하고 그 타입에 대해서 IANA에 등록해야 합니다.(하지만 힘듭니다.) 또한 HTTP Header에 타입을 명시해주어야 합니다.

각 메시지(자원)들은 MIME types에 맞춰 표현되며 스스로를 표현해야 합니다. 또한 이 데이타가 무엇을 나타내는지 path를 통해 나타내주어야 합니다.

{
	"path" : "/kundol"
}

`font/ttf`, `text/plain`, `text/csv`을 정의 해주는 것을 말합니다.

​

1. HATEOAS 구조

하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이타 마다 어떤 URL에서 원했는지 명시해 주어야 합니다.

res.json(personObject, [
	{ rel: "self", method: "GET", href: 'http://127.0.0.1' },
	{ rel: "create", method: "POST", title: 'Create Person', href: 'http://127.0.0.1/person' }
]);

이렇게 하거나 data위에 링크를 써야 합니다.

{
	"link":"http://kundol.net/todos/{id}"
	"data":[]
}

​

2. Stateless

이건 HTTP 자체가 Stateless이기 때문에 HTTP를 이용하는 것만으로도 충족이 됩니다. API를 제공해주는 서버는 세션(session)을 그 서버 쪽에 유지하지 않는다는 의미입니다.

​

3. Cacheable

HTTP 는 원래 캐싱이 됩니다. 새로고침을 하면 304가 뜨면서 원래 있던 js와 css 이미지등을 불러오는 것을 볼 수 있습니다.

이러한 캐싱은 네트워크 요청을 줄여주며 이는 UX향상에 도움이 됩니다. 네트워크 요청시 해당되는 자원들을 복사해서 메모리에 저장해두었다가 또 같은 요청시 네트워크요청을 하지 않고 브라우저메모리에 있던 자원을 다시 반환합니다. HTTP 메서드 중 GET에 한정되어있으며 `Cache-Control:max-age=100`이런식으로 한정된 시간을 정할 수가 있으며 이 캐싱된 데이타가 유효한지를 판단하기 위해 `Last-modifed` 그리고 `Etag`를 씁니다.

`Etag`는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것입니다. 예를 들어 `Cache-Control:max-age=100`으로 형성된 자료는 100초가 지나면 응답이 완료 되었기 때문에 다시 똑같은 자료를 가져올 수 있습니다. 이 때 Etag, 디지털 지문을 사용한다면 똑같은 자원은 캐싱되서 요청을 줄일 수 있습니다

​

4. Client-Server 구조

클라이언트와 서버가 서로 독립적인 구조를 가져야 합니다. 물론 이는 HTTP 를 통해 가능한 구조입니다. 서버에서 HTTP 표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타나게 됩니다. 서버는 그저 API를 제공하고 그 API에 맞는 비즈니스 로직을 처리하면 됩니다. 마찬가지로 클라이언트에서는 HTTP 로 받는 로직만 잘 처리하면 되는 것입니다.

​

5. Layered System

계층구조로 아키텍처를 만들 수 있다는 것을 뜻합니다.

​

URI 규칙

이렇게 규칙을 지켰으면 이제 자원을 표기하는 URI에 아래의 6가지 규칙을 지켜야 합니다.

1. 동작은 HTTP 메소드로 해야 합니다. 수정 = put, 삭제 = DELETE, 추가 = post, 조회 = get을 이용해야 합니다.

예를 들어 `/books/delete/1` 이렇게 표기하면 안된다는 것입니다.

2. 확장자는 표기하지 말아야 합니다.

3. 동사가 아닌 명사로만 표기해야 합니다. **유저가 책을 소유한다**라고 한다면 이런식으로 구성되어야 합니다. `유저/유저아이디/inclusion/책/책아이디`

4. URI는 계층적인 내용을 담고 있습니다. `/집/아파트/전세` 이런식으로 내려가야 합니다.

5. 소문자로 쓰며 너무 길경우에는 **-**를 씁니다.

6. HTTP 응답 상태 코드를 활용합니다.

​

​

​

도서관 REST API 예

도서관의 REST API를 만들 때의 예제를 들고 마무리 하겠습니다.

​

node.js express 예입니다.

app.get('/books/')
// 모든 책을 조회합니다.
app.post('/books/booksid')
// 책을 생성합니다.
app.put('/books/booksid')
// 책을 수정합니다.
app.get('/books/booksid')
// 특정 책을 조회합니다.
app.put('/users/userid/books/booksid')
// 어떤 유저가 특정 책을 빌립니다.
app.patch('/users/userid/books/booksid') 
// 어떤 유저가 특정 책을 빌립니다.

​

참고로 `put`과 `patch`의 차이점은 `put`은 전체 자원의 교체이며 `patch`는 일부자원의 교체를 뜻합니다.

​

예를 들어 `{"a" : 1, "b" : 2}`가 있을 때 b를 3으로 바꾼다 했을 때 `put`의 경우 `{"a" : 1, "b" : 3}`으로 전체적인 인자를 보내고 `patch` 는 `{"b" : 3}`이런식으로 부분적으로 보내는 것을 말합니다. 응답으로 받는 메세지는 수정된 결과값, 동일합니다.

 

 

 

 

출처 : m.blog.naver.com/jhc9639/221005860507