alt
Home RESTful과 Rest 유니폼 인터페이스(Uniform Interface)
Post
Cancel

RESTful과 Rest 유니폼 인터페이스(Uniform Interface)


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>
    


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라는 것을 하나 정의해서 거기에 링크를 박으면 됨
  • 그런데
    1. 클라이언트입장에서 이를 동적으로 파싱해야하기도 하고
    2. 링크 정보가 과다해질 수 있다.(상태전이가 아주 많고 복잡한 경우)
    3. 최소 어떠한 link relation이 있는지를 파악하고 있어야 UI에 바인딩이 가능
    4. 또한, 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

This post is licensed under CC BY 4.0 by the author.