REST 아키텍처 중 Uniform Interface의 self-descriptive messages를 정리한 내용입니다.
self-descriptive messages
유니폼 인터페이스 아키텍처 스타일 중 메세지 스스로 메세지에 대한 설명이 가능해야한다라는 뜻을 가진 제약 조건이다.
서버가 변해서 메세지가 변해도 클라이언트는 그 메세지를 보고 해석이 가능해야하며, 이를 통해 확장 가능한 커뮤니케이션을 달성하는 것이 self-descriptive messages의 목표이다.
Uniform Interface : URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다는 REST 아키텍처 요소 중 하나
self-descriptive messages는 수신자가 메세지를 이해하는 데 필요한 모든 정보가 메세지에 자체에 포함되어 있어야 한다.
이것을 HTTP 요청/응답으로 살펴보자
요청
GET / HTTP/1.1GET / HTTP/1.1
Host: www.naver.com첫 번째 요청은 HTTP 방법과 사용된 프로토콜이 뭔지 알려주지만, 목적지가 없기 때문에
self-descriptive하지 못하지만,
두 번째 요청은 목적지 주소가 존재하기 때문에 해당 메세지가 어떤 메세지인지 알 수 있다. 그러므로 self-descriptive하다고 말할 수 있다.
응답
HTTP/1.1 200 OK
[ {op: "Add", path: "al/ew/qw" } ]응답 메세지는 본문에 JSON 형식의 데이터를 담고 있다. 하지만 클라이언트가 해당 본문이 어떤 데이터 형식인지 알 수 없다.
HTTP/1.1 200 OK
Content-Type: application/json
[ {op: "Add", path: "al/ew/qw" } ]이렇게 Content-Type을 추가하면 이제 클라이언트는 해당 데이터 형식이 json임을 알 수 있다. 그러나, 아직 op가 어떤 의미고 path가 어떤 의미인지는 모른다.
HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[ {op: "Add", path: "al/ew/qw" } ]json-patch+json로 Content-Type을 지정해줌으로써 op의 뜻을 알 수 있게 됐다.
json-patch+json를 설명하는 사이트인데, 국제 인터넷 표준화 기구인 IETF에 미디어 타입으로 등록이 되어있으며, 해당 사이트에서 op를 포함한 json-patch+json의 데이터의 의미를 알 수 있다.
이제 해당 메세지는 self-descriptive해진 것이다.
개발자가 IANA에 미디어 타입을 등록해서 리소스를 리턴할 때 Content-Type으로 사용할 수 있다.
위와 같은 방식으로 self-descriptive messages를 달성할 수 있는 방법 외에도
profile 링크에 해당 메세지의 의미를 알 수 있는 문서를 추가함으로써 달성할 수 있다.
HTTP/1.1 200 OK
Content-Type: application/hal+json
{ "_links" : {
"profile" : {
"href" : "http://example.com/docs/profile"
}
}
}
*HTML을 반환하는 방식은 self-descriptive messages를 잘 지키는 방식 중 하나다.
HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<title>Home Page</title>
</head>
</body>
<div>Hello World!</div>
<a href= “http://www.recurse.com”> Check out the Recurse Center! </a>
<img src="awesome-pic.jpg">
</body>
</html>정리
- self-descriptive messages은 REST의 Uniform Interface 제약조건 중 하나다.
- 오늘날 REST API라 부르는 API는
Self-descriptive를 잘 만족하지 못한다. - 서버나 클라이언트가 변경되더라도 오고 가는 메시지는 언제나 self-descriptive하므로 언제나 해석이 가능하다.
자료 출처
'IT 지식 > REST API' 카테고리의 다른 글
| [REST API] HATEOAS (0) | 2021.07.20 |
|---|---|
| [REST API] REST란 (0) | 2021.06.27 |