컴퓨터의 입력장치 중에는 키보드가 있습니다. 컴퓨터와 통신을 할수있는 방법은 GUI적 용도에 더 맞는 마우스를 제외하면 컴퓨터에 명령을 시킬수 있는 유일한 방법입니다.
특정 단축키를 누르면 특정 기능이 수행되고, 특정 창으로 이동하고 등등 여러 기능을 수행하는 명령을 사용합니다.
API도 그런 기능입니다. 특정 서버에 어떠한 기능을 'Trigger'시키는 역할이죠.
How programs interact with each other.
REST API, GraphQL API, SOAP API, XML API 등 여러가지 api가 존재합니다. 이건 다른 종류의 키보드와 같은 개념입니다.
또한 날씨 api, social network api 등등 다양한 오픈형 api가 존재하여 특정한 기능을 수행합니다.
이중에 REST API는?
[https://www.youtube.com/watch?v=RP_f5dMoHFc&list=TLPQMTAwMjIwMjFD9d49eM0r2Q&index=2](참고영상:REST API로 괜찮은가 YOUTUBE)
REST 아키텍처 스타일을 따르는 API를 뜻합니다.
아키텍처 스타일은 제약조건의 집합으로 모두 지켜야 아키텍처 스타일을 따른다고 할 수가 있습니다.
REST는 분산 하이퍼미디어 시스템(예:웹)을 위한 아키텍쳐 스타일로 아키텍처 스타일이자 하이브리드 아키텍쳐 스타일이라고 말합니다. REST는 아키텍쳐 스타일의 집합체이기 때문입니다.
REST Architecture
REST를 구성하는 스타일
- client-server
- stateless
- cache
- uniform interface
Uniform Interface의 제약조건
identification of resources
- 리소스가 URI로 식별 된다
manipulation of resources through representations
- 리소스를 만들거나 업데이트하거나 삭제 할때 메세지에다가 그 표현을 담아서 전송을하여 그 기능을 수행한다.
self-descriptive messages
- 메세지 자체로 의도,기능,응답이 해석 가능해야 한다.
hypermedia as the engine of apllication state(HATEOAS)
- 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다.- indentification of resources
- layered system
- code-on-demand
Uniform Interface가 여기서 가장 쟁점이라 할수가 있습니다.
이중에서 Self-descriptive message와 HATEOAS는 잘 지켜지지 않고 있습니다.
Self descriptive 하지 않은 message
GET/HTTP/1.1이 요청메세지에는 목적지가 빠져 있기 때문에 self-descriptive하지가 않습니다. 어디서 무슨 작업을 해야하는지 해석이 불가능하기 때문입니다.
GET/HTTP/1.1
Host: www.example.org목적지를 설정해주면 조금더 self-descriptive합니다.
응답 메세지 같은 경우에도 self-descriptive하지 않은 경우도 있습니다.
HTTP/1.1 200 OK
[{"op": "remove", "path": "/a/b/c"}]이런 메세지 같은 경우 status code도 응답하고 json으로 메세지도 전달하지만 self-descriptvie 하지 못한 이유는 이것을 해석하기 위해서는 어떤 문법으로 작성된 것인지 알수가 없습니다. 그래서 content-type header가 담겨 있어야합니다.
HTTP/1.1 200 OK
Content-Type: application/json
[{"op": "remove", "path": "/a/b/c"}]이제 대괄호의 의미가 뭐엇인가, 중괄호의 의미가 무엇인가를 알수 있고 파씽이 가능해집니다.
Content-Type: application/json-patch+json사실 컨텐츠 타입이 저렇게 해야 완벽합니다. json patch라는 명사를 찾아가서 이를 이해한 다음 이 메세지를 올바르게 이해할수가 있습니다. 이제서야 이 메세지의 온전한 이해가 가능합니다.
HATEOAS
애플리케이션 상태의 전이
위에는 간단한 책 게시판의 애플리케이션 플로우입니다. [글 목록 보기]링크를 통해 어떤한 글들이 존재하는지 GET하고 [글쓰기]링크를 통해 글의 양식을 GET하고 그 글 양식을 [글저장] 링크를 통해 POST하여 저장한 후 내가 저장한 글을 보고 또 그 저장한 글을 글 목록에 추가가 됩니다. 이렇게 상태를 전이하는데 이용한 것은 "[]"로 묶여 있는 링크를 통해서 상태를 전이합니다. 이상태를 전이할때 마다 링크를 통해 전이를 했기 때문에 HATEOAS를 만족합니다.
Why Uniform Interface?
독립적 진화를 위해
- 서버와 클라이언트가 각각 독립적으로 진화한다.
- 서버의 기능이 변경 되어도 클라이언트를 업데이트할 필요가 없다.
- REST를 만들게 된 계기: "How do I improve HTTP without breaking the web
각각 독립적으로 서버와 클라이언트의 운영이 가능하고 기존에 쓰고 있는 웹서버가 바뀌어도 접속이 가능하다는 점. 그만큼 독립적이고 상호 의존성을 낮추는 기능입니다.
좀더 쉽게 REST API
API는?
어떤 기계를 만들면 사용자가 모든 기능을 사용할수 있도록 제어 장치가 마련되어야합니다. 티비의 기능을 이용하기 위해 리모콘이 있고 컴퓨터의 기능을 이용하기 위해 키보드가 있습니다. 이는 Interface라고 합니다. 명령을 내리는 장치 뿐만이 아니라 결과 값을 노출하는 TV와 컴퓨터 모니터 자체도 Interface에 속합니다. 기계와 인간과의 소통 창구라고 생각하시면 될 것 같습니다.
소프트웨어 같은 경우 소프트웨어 장치들이 있습니다. 버튼이나 스크롤바 메뉴창 등 User Interface들이 존재합니다. 사용장들이 웹사이트의 기능을 이용하기 위한 제어 장치입니다.
하지만 소프트웨어에서는 보이지 않는 소통이 이루어지는 곳도 있습니다.
앱 또는 웹과 서버, 기계와 소프트웨어, 소프트웨어와 소프트웨어 끼리 많은 기능을 요청하고 응답합니다. 이를 접근하고 또한 결과를 표현할수 있는 소통 방법이 필요합니다. 미리 지정 된 형식으로 요청, 응답을 하면 공개된 매뉴얼이 있으면 서로 소통하는 수단이 바로 API(Application Programming Interface입니다.
REST API
REST API는 Front가 소버와 소통하거나 앱에서 특정 기능을 서버와 통신하기 위해 널리 사용되는 하나의 API 형식입니다. 과거의 SOAP이라는 복잡한 API형식을 대체한 형식입니다.
REST API의 가장 중요한 점은 위에서도 설명 드린 Self-descriptive, 즉 요청 자체로 이 api의 기능이나 목적이 추론이 가능해야 한다는 점입니다.
이를 잘 지키는 api를 RESTful 한 API라고 합니다. 즉 REST API가 조금더 명확한 기능을 추론이 가능하고 직관적으로 설계가 되었다면 RESTful API라 할수 있고 우리는 조금 더 RESTful한 API를 설계하도록 노력할 필요가 있습니다.
Why RESTful
사실 혼자서 개발을 한다면 그냥 아무런 의미를 주어서 api 주소나 형시을 만들어도 됩니다.
글의 목록을 가져오는 주소를 그냥 Happy라 설명한 URI를 만들어도 되고 글저장 기능을 Hello라는 URI로 설계해도 됩니다. 하지만 개발은 혼자서 하는 것이 아니라 현재 웹 세대는 Front와 Back이 나누어져 있는 상태고 또한 다른 개발자가 나의 api를 사용해 기능을 접근할 필요가 있을 수도 있고 누군가 인수/인계를 받을 수도 있습니다. 더 복잡해진 웹/앱 서버의 기능들을 모두 관리하고 효율적으로 사용하기 위해서는 RESTful API가 가장 이상적이기 때문에 더욱 RESTful한 api를 만들고자 하는 것입니다.
