HTTP API
- HTTP를 사용해서 서로 정해둔 스펙으로 통신
- 넓은 의미의 Rest API
REST API(Restful)
: http api와 같으나 추가적으로 Restful한 네가지 특징을 갖고 일관된 인터페이스를 만들어야 한다.
1. 자원 식별: 각각의 리소스는 URI를 통해 식별 가능해야한다.
e.g) GET /rooms/1
- 리소스의 표현 방법 종류: document, collection, store, controller
URI vs URL
- URL은 URI의 한 부분. Resource에 어떻게 접근하는지를 나타내는 Path
- URI는 Client, Server간 리소스의 Representation을 교환하기 위한 방법. 시간이 흘러도 변하지 않는 정보를 포함한 Identifier
2. 메시지(표현, 행위)를 통한 리소스 조작: 자원을 어떻게처리할 지 표현을 전송한다.
GET, POST, PUT, DELETE, PATCH 메서드 뿐 아니라, 자원의 표현
Resource에 대한 상태를 설명하는 Representation을 주고 받음.
- Representation 형태는 content-type.
text/html
,application/json
등
e.g) html을 선호하는 한국 사용자를 위한 representation
Content-Type: text/html; charset=UTF-8 Content-Language: ko <html><body>안녕하세요</body></html>
- Representation 형태는 content-type.
3. 자기 서술형 메시지: 수신자가 이해하기 위한 모든 정보를 가지고 있어야 한다.
별다른 문서를 제공받지 않고, REST API 메시지만 보고도 쉽게 이해할 수 있도록 자기서술적이다.
method, status code, Header 등 HTTP 표준을 적극 활용
GET /HTTP /1.1
1 2
HTTP/1.1 200 OK \[{ “op” : “remove”, “path” : “a/b/c"}\]
이러한 메시지보다 아래의 메시지가 더 self-descriptive
GET /HTTP /1.1 Host: www.test.co.kr
1 2 3
HTTP/1.1 200 OK Content-Type: application/json-patch+json \[{ “op” : “remove”, “path” : “a/b/c"}\]
4. hateoas : 클라이언트가 리소스에 접근하기를 원한다면, server가 응답을 줄 때 hyperlink를 추가해서 보내준다. 다음에 클라이언트가 어떤 API를 호출해야하는지는 해당 링크를 통해 받을 수 있다.
이 원칙을 통해 클라이언트와 서버는 완전하게 분리됨.
오토마타에서의 상태전이와 비슷하게 이해 가능하다.
URI 등이 바뀌어도 클라이언트에서는 자동으로 연결됨
클라이언트에게 자원을 보내면서 다음에 연결할 URL을 링크로 같이 보내기 때문에
- e.g) 주문에 대한 정보를 보낼 때 주문 고객에게 사용 가능한 작업을 식별하는 링크를 주문 presentation에 포함
요청에 대한 응답을 보낼 때 그 스크린에서 할 수 있는 것들을 요청으로 보내면 됨
ref) https://docs.microsoft.com/ko-kr/azure/architecture/best-practices/api-design#use-hateoas-to-enable-navigation-to-related-resources
이 원칙이 중요한 것은 이렇게 함으로서 클라이언트와 서버간의 완전한 분리가 이루어지게 됩니다. 만약 서버의 자원을 나타내는 URI 가 변경되었을 경우 클라이언트는 서버의 변화에 종속적으로 그 정보를 클라이언트 정보에 추가하게 됩니다. (SPA 상에서 href 데이터를 바꾸어 줘야함) 하지만 HATEOAS를 제대로 적용했을 시 아래와 같이 _links.profile 에 대한 href정보만 조회해주면 되므로 서버에서 URI정보가 바뀌어도 클라이언트 측에서 소스 변경없이 그대로 사용할 수 있게 됩니다.
출처: https://engkimbs.tistory.com/855 [새로비]
e.g )
1
2
3
4
5
6
7
8
"_links" : {
"self" : {
"href" : "http://localhost:8080/api/events/46"
},
"profile" : {
"href" : "/docs/index.html#resources-events-get"
}
}
HATEOAS가 어려운 이유
- html으로 전달하는 방법 말고 JSON의 경우에는 본문에
link
라는 것을 하나 정의해서 거기에 링크를 박으면 됨 - 그런데
- 클라이언트입장에서 이를 동적으로 파싱해야하기도 하고
- 링크 정보가 과다해질 수 있다.(상태전이가 아주 많고 복잡한 경우)
- 최소 어떠한 link relation이 있는지를 파악하고 있어야 UI에 바인딩이 가능
- 또한, URI 변경 말고, link relation이 변경되면, 우리가 변경에 대한걸 반영해야 하는 것은 여전하기도 함
reference)
https://doitnow-man.tistory.com/96
https://blog.npcode.com/2017/04/03/rest%ec%9d%98-representation%ec%9d%b4%eb%9e%80-%eb%ac%b4%ec%97%87%ec%9d%b8%ea%b0%80/
https://www.inflearn.com/questions/126743
http://amazingguni.github.io/blog/2016/03/REST%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4-1
https://sabarada.tistory.com/9
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=saltynut&logNo=220758336130