[CS지식] REST API 에 대해서
요즘 많은 곳에서
REST API 작성을 했다.` REST API를 따른다.`이런 글 들을 많이 보고 있었고 나 역시도 실전 프로젝트 당시에는 잘 모르고 사용했던 것 같다.
이번 글에서 알아보도록 하려고 한다.
REST
Representational State Transfer의 약자로 월드 와이드 웹 (www)과 같은 분산 하이퍼 시스템 아키텍처의 한 형식.
주고받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP메서드 (GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고받는 것.
API
Application Programming Interface 의 약자로 애플리케이션에서 제공하는 인터페이스를 의미한다.
REST API
REST 아키텍처를 따르는 시스템 / 애플리케이션 인터페이스.
REST의 URI 설계 규칙
- URI의 마지막에는 ‘/’를 포함하지 않는다.
- 언더바(_)를 사용하지 않는다. 대신에 하이픈(-)을 사용한다.
- 하이픈의 경우 리소스의 이름이 길어지면 사용
- URI에는 행위(동사)가 아닌 결과(명사)를 포함한다.
- 행위는 HTTP 메서드로 표현할 수 있어야 한다.
- URI에는 소문자로 작성한다.
- 파일의 확장자는 URI에 포함하지 않는다.
- HTTP에서 제공하는 Accept - Header를 사용하자.
REST의 특징
- Stateless
- 서버에 상태 정보를 따로 보관하거나 관리하지 않는다.
- 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도 보관하지 않는다.
- 모든 요청에 대해 개별적으로 처리한다.
- 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순하다.
- cache
- HTTP Cahcing 기능을 사용할 수 있다.
- 응답, 요청이 모두 캐싱 가능한지 명시가
- 캐싱이 가능한 경우 클라이언트에서 캐시를 저장해두고 같은 요청에 대해서는 해당 데이터를 사용
- layered system
- REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다.
- client-server architecture
- REST 서버는 API를 제공
- 클라이언트는 사용자 정보를 관리하는 구조
- Uniform Interface
- identification of resources
- 리소스가 URI로 식별되면 된다.
- manipulation of resources through representations
- HTTP 메서드를 통해 해당 자원의 상태를 주고 받는다.
self-descriptive messages- 메세지는 스스로를 설명해야 한다.
hypermedia as the engine of application state(HATEOAS)- Hyperlink를 통한 애플리케이션 상태의 전의
- identification of resources
위의 특징들 중 Uniform Interface의 self-descriptive messages, HATEOAS 이 부분을 많은 사람들이 잘 지키지 않는 부분이다. 이 특징들에 대해 알아보도록 하자.
Self-descriptive message
메세지는 스스로를 설명해야한다.
[요청 메세지 1]
GET / HTTP/1.1
요청 메세지 1의 경우 목적지가 없기 때문에 self-descriptive 하지 못하다.
[요청 메세지 1의 self-descriptive 한 메세지]
GET / HTTP/1.1
Host: www.tommyworld.org
[요청 메세지 2]
HTTP/1.1 200 OK
[
{"op": "remove", "path":"/a/b/c"}
]
요청메세지 2의 경우 어떠한 문법으로 작성된 것인지 해석을 못한다.
[요청 메세지 2의 self-descriptive 한 메세지]
HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[
{"op": "remove", "path":"/biscuits"}
]
json-patch+json 의 명세를 보고 어떠한 내용인지 알 수 있다.
Hypermedia as the engine of application state
애플리 케이션의 상태는 Hyperlink를 이용해 전이 되어야 한다.
[Http 명세 ]
GET / HTTP/1.1
Content-Type: text/html
<html>
...
<body>
<a href = "/next"> next </a>
</body>
</html
Http 명세의 경우 a 태그를 통해 전이가 가능하다.
[Json 명세]
GET / HTTP/1.1
Content-Type: application/json
Link : </post/1>; rel="previous",
</post/2>; rel="next"
{
"title" : "hello",
"content" : "..."
}
Json 명세의 경우 Link를 통해 전이가 가능하다.
Self descriptive message, HATEOAS 를 만족하지 않아도 관계는 없다.
하지만 REST를 정의한 로이필딩에 의하면 REST라고 할려면 모든 규칙을 만족 해야 한다고 한다.
정보 출처 : 그런 REST API로 괜찮은가?
댓글남기기