최근에 웹 API를 "정말 RESTful"로 만드는 제약 조건 인 HATEOAS (Engine of Application State)로서 Hypermedia에 대해 읽었습니다. 기본적으로 현재 상태에서 가능한 전환에 대한 모든 응답이 포함 된 링크를 포함합니다.
내 이해를 바탕으로 HATEOAS가 무엇인지 설명해 드리겠습니다. 무언가를 놓친 경우 수정 해주세요.
/
GET: {
"_links": {
"child": [
{ "href": "http://myapi.com/articles", "title": "articles" }
]
}
}
/articles?contains=HATEOAS
GET: {
"_items": [
{ "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" },
{ "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" }
],
"_links": {
"self": { "href": "http://myapi.com/articles", "title": "articles" },
"parent": { "href": "http://myapi.com/", "title": "home" }
}
}
POST: {
"title": "A New Article",
"body": "Article body",
"tags": [ "tag1", "tag2" ]
}
/articles/0
GET: {
"title": "Why Should I Care About HATEOAS?",
"body": "Blah blah blah"
"tags": [ "REST", "HATEOAS" ],
"_links": {
"self": { "href": "http://myapi.com/articles/0", "title": "article" },
"parent": { "href": "http://myapi.com/articles", "title": "articles" }
}
}
HATEOAS는 두 가지 주요 이점을 제공한다고 주장합니다.
루트 URI부터 전체 서비스를 검색 할 수 있으며 더 이상 문서가 필요하지 않습니다.
클라이언트는 서버에서 분리되어 URI 구조를 자유롭게 변경할 수 있습니다. 따라서 API 버전 관리가 필요하지 않습니다.
그러나 내 견해로는 서비스는 URI 구조보다 훨씬 많습니다. 효과적으로 사용하려면 다음 사항도 알아야합니다.
- 사용할 수있는 쿼리 매개 변수 및 가능한 값
- POST / PATCH / etc 요청으로 보내야하는 JSON / XML / 문서의 구조
- 서버가 보낸 응답의 구조
- 발생할 수있는 오류
- ...
위의 내용을 바탕으로 HATEOAS는 발견 및 커플 링 문제의 작은 부분 만 해결합니다. 여전히 위의 네 가지 측면을 문서화해야하며 클라이언트는 여전히 서버와 강력하게 연결됩니다. 클라이언트 중단을 피하려면 여전히 API 버전을 수정해야합니다.
그것이 제공하는 유일한 장점은 더 많거나 적은 자유롭게 (원칙에 무슨 일이 있었는지 방식에 의해 당신의 URL 구조를 변경할 수 있다는 것입니다 "변경하지 않는 쿨의 URI" ?). 이해가 정확합니까?