Rest API

RestAPI를 충족시키기 위해서는 Self-Descriptive Message와 HATEOAS(Hyptermedia as the engine of application state)를 만족해야한다.

• API : Application Programming Interface

• REST

  • REpresentational State Transfer
  • 시스템 제각각의 독립적인 진화를 보장하기 위한 방법
  • REST API : Rest아키텍처 스타일을 따르는 API
  • 아키텍처스타일
    • 클라이언트-서버구조
    • stateless
    • cache
    • uniform interface
    • layered system
    • code-on-demand(optional)
  • Uniform Interface
    • Self-descrive message
    • Identification of resource
    • HATEOAS
    • manipulation of resources through representations

• Self-descriptive message

  • 메세지 스스로 메세지에 대한 설명이 가능해야한다. => 응답만 가지고 메세지 자체를 해석할 수 있어야된다. 해석을 위한 profile link를 주는게 좋다. Github API가 REST의 모범사례

    • // Case1
      {"langcode":"ko"} // Bad Case
      
      // Case2
      // 닮은 유명인을 찾은 경우
      {
       "info": {
         "size": {
           "width": 900,
           "height": 675
         },
         "faceCount": 2
       },
       "faces": [{
         "celebrity": {
           "value": "안도하루카",
           "confidence": 0.266675
         }
       }, {
         "celebrity": {
           "value": "서효림",
           "confidence": 0.304959
         }
       }]
      }
      
      // 닮은 유명인을 찾지 못한 경우
      {
      	"info": {
      		"size": {
      			"width": 768,
      			"height": 1280
      		},
      		"faceCount": 0
      	},
      	"faces": []
      }
      

    • 위의 Case2도 데이터의 나열만 되어있지 응답을 보고서 어떤 역할을 하는지 모르기 때문에 문서를 봐야된다. 따라서 Self-descriptive라고 할 수 없다. 이를 해결하기 위해 profile이라도 추가해서 응답에 대한 해석을 도와줘야한다. 그래도 HATEOAS를 만족하지 않는다.

    • Case3도 Content-Type을 text/xml로 했다. 하지만 밑에 rss태그들을 브라우저가 해석을 못할 수 있다. 이 부분만 해결되면 Self Descriptive라고 할 수 있다. HATEOAS는 만족한다. link 태그에 url이 있다.

  • 서버가 변해서 메세지가 변해도 클라이언트는 그 메세지를 보고 해석 가능해야한다.

  • 확장 가능한 커뮤니케이션

• HATEOAS

  • 하이퍼미디어(링크)를 통해 애플리케이션 상태 변화가 가능해야한다. => HTTP 메서드를 이용해서 CRUD를 주로 활용, Response 내에 있는 URL을 통해 다음 상태를 갈 수 있어야한다.
  • 링크 정보를 동적으로 바꿀 수 있다.(versioning없이)

• Self-Descriptive Message 해결방법

  • 방법1 : 미디어타입을 정의하고 IANA에 등록하고 그 미디어 타입을 리소스 리턴할 때 Content-Type으로 사용
  • 방법2 : profile 링크 헤더를 추가한다. 브라우저들이 아직 스펙을 잘 지원안하기 때문… 응답 본문에 HAL스펙에 따른 profile링크추가

• HATEOAS해결방법

  • 방법1 : 데이터에 링크 제공. 링크를 어떻게 정의할 것인가? HAL스펙에 따른다.

  느낀점

  • 많이들 RestAPI에 대해서 이야기를 한다. 데뷰에서 발표한 RestAPI에 관한 강의를 들으면서 그동안 잘못알고 있다고 느꼈다. 서버-클라이언트 구조로 나뉘고, HTTP 메서드와 URI를 통해 데이터에 대해 CRUD를 하고 그 결과를 JSON형태로 응답해주면 그게 RestAPI인줄 알았다. 데뷰에서 느꼈던것은 API자체가 self-descriptive message형태로 메세지 스스로가 설명가능해야하고, HATEOAS를 통해 상태전이가 가능해야된다고 설명이 있었다. 어떻게 만들까에 대해서 잘 몰랐지만, 강의를 통해 어느정도 익힐 수 있었다. Hateoas와 spring rest-doc 등을 잘 활용해서 최대한 rest-api에 맞는 형태로 설계를 해봐야겠다.