[GDSC] Spring 스터디 1주차

REST API란 무엇인가

외부로 접근할 수 있는 웹 API 중 하나

REST : REpresentational State Transfer

• 인터넷 상의 시스템 간의 상호 운용성(interoperability)을 제공하는 방법중 하나
• 그런 REST API로 괜찮은가 (https://www.youtube.com/watch?v=RP_f5dMoHFc)
• 오늘날의 REST API는 REST API라고 할 수 없다. 뒤의 두 가지 조건을 만족하지 못하는 것이 많다.
  • Identification of resources
  • manipulation of resources through represenations
  • self-descrive messages
  • hypermedia as the engine of appliaction state (HATEOAS)

Self-descriptive message

• 메시지 스스로 메시지에 대한 설명이 가능해야 한다.
• 서버가 변해서 메시지가 변해도 클라이언트는 그 메시지를 보고 해석이 가능하다.
• 확장 가능한 커뮤니케이션

HATEOAS

• 응답에 어플리케이션의 상태변화가 가능한 하이퍼미디어(링크) 정보가 담겨 있어야 한다.
• 하이퍼미디어를 통해 클라이언트가 다른 상태로 전이할 수 있어야 한다.
• 링크 정보를 동적으로 바꿀 수 있다. (Versioning 할 필요 없이!)

네이버 예제

파파고 API를 살펴보았다.

응답 예제를 보았을 때 자체로 무엇을 뜻하는지 전혀 알 수 없음. -> self-descriptive하지 않음

다음 상태로 전이할 수 있는 링크도 제공되지 않음.

클로바 API를 살펴보았다.

응답 예제를 보았을 때 데이터만 나오고, 무엇을 뜻하는지는 문서를 참고해야함.

그리고 문서에 대한 링크가 응답에 포함되어있지도 않음.

self-descriptive해지려면 응답을 해석할 수 있는 정보인 문서 링크를 걸면 된다.

그럼에도 다음 상태로 전이할 수 있는 링크가 없기에 HATEOAS 만족하지 않음

검색 API를 살펴보았다. -> REST API 맞...을 뻔했다.

self-descriptive 할 뻔했다. rss로 컨텐츠 해더를 주었어야 한다.

HATEOAS 만족. 링크 정보가 들어있다.

 

kakao 예제

REST API라고 할 수 없다.

응답 컨텐츠 타입이 json이라 나오는데 이것만으로는 응답을 해석할 수 없다.

profile 링크가 제공되어 응답에 대한 해석이 가능해야한다.

HATEOAS도 만족하지 못했다.

vision API도 데이터만 있고, 해석 정보는 주어지지 않음.

 

GitHub 예제

REST API 만족!

헤더를 모두 IANA에 등록해놓았다.

응답에 대한 미디어 타입을 정의하고, 그 미디어 타입에다 각각 들어올 메세지를 정의해 놓았다.

이것말고 다른 방법은 프로필로 링크를 거는 방법.

HATEOAS를 만족하는지 보기 위해 링크가 있는지 살펴보았다.

hal이라는 스펙을 따르지는 않지만 메세지 나름대로 다음상태로 전이할 수 있는 url 정보들이 많이 담겨있다.

클라이언트 입장에서는 url 템플릿을 직접 입력할 필요없다.

이 강좌에서 어떻게 REST API를 구현할 것인가

self-descriptive message 해결방법

1. 미디어 타입을 정의하고 IANA에 등록하고 그 미디어 타입을 리소스 리턴할 때 Content-Type으로 사용한다.
2. profile 링크 헤더를 추가한다.
   • 브라우저들이 아직 헤더에 링크를 추가하는 방법에 대한 지원이 되지 못한다.
   • 대안으로 HAL의 링크 데이터에 profile 링크 추가
   • 헤더에 추가하지 않고 본문에 링크 정보를 제공할 것.

HATEOAS 해결 방법

1. 데이터에 링크 제공 - HAL 사용
2. 링크 헤더나 Location을 제공