REST API, 그런 REST API로 괜찮은가

ㅎㅎ·2023년 8월 25일

추후 내용을 보기 좋게 정리할 예정

What is REST API?
- 어플리케이션을 개발할 때 개발자들 사이에서 정보를 주고 받는 형식을 규정해 놓은 것, API를 통해서 서버와 클라이언트가 주고받는 메시지를 명확히 하여 메시지만으로 어떤 요청과 응답을 하는지 알 수 있어야 함. 요청을 할 때는 조작하려는 자원과, 행위를 HTTP 메소드와 URI로 명시하여 누구라도 쉽게 해당 요청이 무엇을 요구하는지 알 수 있도록 함.
WHY do we use REST API?
- 개발을 하게되면 여러 개발자가 함께 하고, 인수인계를 하기도 하며, 개발한 기능을 여러 어플리케이션에서 각자의 목적대로 이용할 수 있는데, 이때 그 요청과 응답을 명확하게 알 수 있도록 하여 개발의 확장성을 높임.
What is exact REST API?
- 일반적으로는 자원의 명시와, 행위의 표현 두 가지가 REST API라고 일컬어지지만, 사실 이는 HTTP 메소드와 URI만으로도 만족시킬 수 있다. 하지만 진정한 REST API는 클라이언트와 서버 구조에서 서로 독립적으로 개발이 가능하도록 API를 설계하는 것을 말한다. 이를 위해서는 unifrom interface라는 제약 조건의 집합 중에서 자기서술적 메시지와 hateoas라는 조건까지 만족해야만 한다. 자기 서술적 메시지는 메시지만으로 추가적인 설명 없이도 API를 이용할 수 있어야 한다는 것이고 HATEOAS는 API가 하이퍼미디어적으로 동작해야 한다는 것이다. 하이퍼미디어 적으로 동작한다는 것은 메시지 내에서 필요한 다른 미디어-텍스트 컨텐츠로 자유롭게 이동할 수 있도록 링크가 제시되어야 한다는 것이다. 이 두 가지 조건만 만족한다면 서버에서 API를 어떻게 지지고 볶고 바꾸고 업데이트해도 클라이언트는 업데이트할 필요가 없다. 명확한 메시지의 내용과 구조만을 이용해 클라이언트 단을 개발할 수 있기 때문이다. 이렇게 2가지 조건 모두가 추가로 지켜져야만 진정한 의미의, 서버와 클라이언트간 독립이 가능한 REST API가 완성된다. 하지만 이는 이상적이다. 왜냐면 응답 메시지로 주로 이용하는 JSON은 사실 KEY:VALUE에 대한 합의 사항이 없다. 개발자가 자유롭게 의미를 부여하고 사용한다. 그래서 우리가 개발할 때도 API 명세를 작성하지 않는가? 따라서 조건을 충족시키기 위해서 JSON의 의미를 명세로 만들어 공식적으로 등록하든지 하는 방법들을 이용해야 하는데, 시간 소모가 크다. 이외에도 여러가지 이유로 2가지 조건 충족에는 제약이 있고, 현실적으로 엄밀한 REST API를 쓰기는 어렵다. 그런 REST API로 괜찮은가의 발표자는 조건이 충족되지 않은 REST API를 REST API로 부르지 말거나, 조건을 준수하거나, 조건을 준수하지 않고 REST API로 그냥 부르거나 3가지 방안이 있다고 한다. 마지막 방안은, 로이필딩이 마음에 들어하지 않을 것이라고...

REST API: 정보들이 주고받아지는데 있어서 개발자들 사이에 널리 쓰이는 일종의 형식, 형식이기 때문에 어떤 언어, 소프트웨어,프레임워크를 쓰든 이 FORM에 맞춰 기능을 만들면 됨

API?

기계와 기계, SW와 SW 사이에 수많은 정보교환이 이루어지는데, 이들 사이에 소통할 수 있는 창구가 필요, 기상청 서버로부터 다양한 앱, 웹들 사이에 정보가 요청되고 전송됨. 기상청 서버에게 정보를 요청하는 지정된 형식이 있어야 함, 또한 응답이 오는 형식에 대한 기대도 있음. 이처럼 SW와 SW가 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API라고 함

REST?

요청을 보내는 주소만으로도 뭘 하는 요청인지 파악 가능하도록 URI를 구성하는 것, 다른 개발자도 쉽게 파악 가능하고, 다양한 곳에서 사용해도 혼동이 없도록 함.
Representational State Transfer

Rest가 어떤 계기로 나왔는가?

WEB(1991) - 팀 버너스리
Q. 어떻게 인터넷에서 정보를 공유할 것인가?
A. 정보들을 하이퍼텍스트로 연결한다. (표현형식 HTML, 식별자 URL, 전송방법 HTTP )

로이 필딩: "How do I improve HTTP without breaking the Web?"

HTTP 1.0을 정립하는 과정에 참여하면서, 이미 HTTP를 이용하고 있는 웹서버들이 있는데 어떻게 웹을 망가트리지 않고 HTTP를 진보시킬 수 있을까 고민 -> 해결책: HTTP Object Model, 이것을 발전시켜 REST를 논문으로 발표

한편... API?
XMP-RPC(1998) by Microsoft
원격으로 단일 시스템에 메소드를 호출할 수 있는 rpc라는 프로토콜을 만들고 이게 나중에 SOAP으로 바뀜

Salesforce API가 API를 발표: 인터넷에서 거의 최초로 쓰인 API

ID로 Object 하나를 가져오는 API 코드가 위와 같았음, 너무 복잡

4년후 flickr API 공개

그런데...

버저닝이 뭐여

CMS는 뭐여

로이필딩: Rest APIs must be hypertext-driven
REST API를 위한 최고의 버저닝 전략은 버저닝은 안 하는 것

사람들이 말하는 REST랑 로이필딩이 말하는 거랑 너무 차이가 난다. 왜 그런 걸까? 뭐가 문제일까?

로이필딩 논문에 아래와 같이 나와 있음

아키텍쳐 스타일은 뭔가?

이 제약조건을 모두 지켜야 rest를 따른다는 것이 가능함

REST가 어떤 제약조건으로 구성돼잇나?

rest를 하이브리드 아키텍처 스타일이라고 말하기도 함. 여러 아키텍처 스타일의 집합임

대체로 오늘날 REST API로 불리는 것들은 위 스타일을 잘 지키고 있는데, 그 이유는 이미 HTTP만 잘 따라도 잘 지켜지고 code-on-demand 같은 경우는 JavaScript가 지키게 만든다.
code-on-demand? 서버에서 코드를 클라이언트로 보내서 실행시킬 수 있어야 한다. -> JavaScript
대체로 다 만족하는데 unifrom interface를 잘 만족하지 못 함

1번은 resource가 uri로 식별되면 된다.
2번은 representaion 전송을 통해서 resource를 조잭햐아 한다.
- 어떤 resource를 만들거나 업데이트하거나 삭제하거나 이럴 때 http message에다가 표현을 담아서 전송해서 달성해야 한다.
Q. 아니 근데 근본적으로 REST API를 왜 쓰지? 개발자들 사이에 규칙으로 누구나 URI만으로 어떤 자원에 대해 어떤 요청을 하는지 식별 가능 하도록 하기 위해?
나머지 2개가 문제: 거의 모든 자칭 rest api라고 알려진 거의 모든 것드리 이 2가지는 지키지 못 하고 있다.
- self-descriptive
- hateoas
- SEFLT-DECRIPTIVE? 메시지가 스스로 설명할 수 있어야 한다.
  
  이게 어떤 문법으로 작성한건지 모르니까 클라이언트에서 해석을 못 함 이렇게 JSON 형식임을 알려야 대괄화, 중괄호, 큰따옴표, 콜론이 뭔지 알고 파싱을 할 수 있다. 하지만 이것도 완전하지 못하다. OP는 뭐고, PATH는 뭔지 몰라서 아래와 같이 해야만 json-patch+json라는 미디어타입으로 정의된 메시지이기 때문에 이에 대한 명세를 찾아가서 이 메시지를 해석하면 이 메시지를 올바르게 해석할 수 있다. 이처럼 메시지 만으로 온전히 해석이 가능해야 하는데 오늘날 rest api는 그냥 json으로만 돼있지 어떻게 해석해야 하는지까지 보내주진 않는다. Q.JSON patch가 뭐여?

HATEOAS? 어플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
아래와 같은 흐름을 application으 ㅣ상태를 전이한다고 한다. 이 상태의 전이마다 해당 페이지의 링크를 따라서 전이했기 때문에 말그 대로 hyper link를 통한 전이가 됨.

html은 hateos를 만족함. a 태그에 hyperlink를 등록하고 전이할 수 있음
json으로 하면? Link라는 header가 이 resource와 연결되어 있는 다른 resource를 가리킬 수 있는 기능을 제공함. 이전가 다음 article에 대한 uri 정보를 표현하고 있음. 또한 이 정보는 Link header가 이미 표준으로 문서가 나와있기 때문에 이 메시지를 보는 사람이 온전히 해석을 해서 어떻게 링크가 돼있는가를 이해하고 hyperlink를 타고 다른 상태로 전이가 가능함. 따라서 htaeos를 만족한다.

로이필딩이 고민했던 것, HTTP를 어떻게 WEB을 해치지 않고 개선할 수 있을까?

Q.근데 HTTP 버전이 달라지면 WEB이 깨지나? 그 이유가 궁금하네. GET, POST 이런 메소드나, URI 관련해서 변경이 있나? 아니면 내부 메시지 상에 뭔가 바뀌니까?

Q.서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요가 없다는 게 잘 이해가 안 간다. 하이퍼미디어가 어떻게 독립적으로 진화할 수 있게 해주는지 이해가 안가. 새로운 리소스나 기능을 추가하면 endpoint가 추가되거나, 변경될 수도 있잖아. 근데 어떻게 클라이언트에는 영향을 주지 않을 수 있는 거지?

Q.구체적인 예시를 알려줄 수 있어? 뭐 예를 들어 회원정보 조회를 위해 member/1이라는 endpoint가 있었는데, 이걸 서버에서 user/1로 바꿔버렸어. 그러면 클라이언트 단에서는 이 API를 호출하는 코드 부분을 필연적으로 수정해야 하는 거 아니야?

실제로 rest api는 잘 지켜지고 있는가? 웹 페이지에서 잘 지켜지고 있다.
웹페이지가 변경됐다고 그 웹페이지에 접속할 때 웹브라우저를 업데이트하지 않는다.URI가 바뀌든, 내요잉 바뀌든, 그림이 바뀌든..
읍붸라우저를 업데이트해도 웹페이지 접근이 가능하다.
HTTP 명세가 변경되어도 웹은 잘 동작한다.
HTML 명세가 변경되어도 웹은 잘 동작한다.

모바일 앱은 .. 안 된다네?

서버가 기능을 변경했는데, 모바일 앱이 이 기능을 지원해주지 못 할 때가 많음.

웹은 어떻게 가능하게 했을까?

놀라운 마법으로 한방에? X, 피땀흘려 노력함.
기능추가없이 문서를 다듬기만하는데도 7년, 호환성을 깨드리지 않기 위해.

상호운용성이 어떻게 꺠지는지 와닿지가 않네 내가 아직 배경지식이 부족한듯

HTTP 1.0이 나온지 20년이 넘었는데 그 전에 나온 0.9를 지원을 못 하고 잇음, 뺐더니 일부 프락시에서 오동작이 발견되서 웹을 깨트리니까....

웹소켓도 막 Edge에서는 지원이 안되고 하는 어떤 브라우저에서 지원이 안되는 버전이 있잖아. 그래서 이 지원안되는 브라우저를 해결하기 위해 업그레이드하는 뭔 코드를 추가하고, 그런 거처럼 서버가 HTTP 통신 API를 구현해놨는데, HTTP가 발전되서 이 API를 수정했어. 근데 웹브라우저나, 클라이언트 코드가 이걸 해석할 수 없게 되거나 하는 등 호환성에 문제가 발생할 수 있따 이런건가