[Other]REST APIについて

REST APIとは?

REST APIとは、RESTアーキテクチャスタイルに従うAPIのことである.
開発者に広く使われる形式として、
プログラミング言語、フレームワーク/ソフトウェアなどの技術に制限されません.
所定の形式で機能を作ればいいです.

REST?

REpresentational State Transfer
Webなどの分散型スーパーメディアシステムのアーキテクチャスタイル(制約の集合).
HTTP URI(Uniform Resource Identifier)でリソースを指定します.
HTTP方式(POST、GET、PUT、DELETE)による
これは、リソースに対してCRUD操作を適用する方法である.
=>ResourceがHTTPメソッドでResourceを処理するように設計されているかどうか.

API?

アプリケーションプログラミングインターフェース:アプリケーションプログラミングインターフェース
アプリケーションプログラミングインターフェース.
要求、コマンドを指定した形式(サブルーチンまたはプロトコル)で受け入れるインタフェース仕様.

RESTのスタイルの設定(制約)

client-server: REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을
직접 관리하는 구조로, 각각의 역할이 확실히 구분되는 것.
클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어들게 된다.

stateless(무상태성): 작업을 위한 상태정보를 따로 저장하고 관리하지 않기에 무상태성을 띈다.
API 서버는 세션이나 쿠키 정보를 별도로 저장하고 관리하지 않고, 단순히 들어오는 요청만을 처리하면 된다.
서버에서 불필요한 정보를 관리하지 않아 구현이 단순해진다.

cacheable(캐시 가능): HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를
그대로 활용할 수 있다. 따라서 HTTP가 가진 캐싱 기능을 적용할 수 있다.

layered system: REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해
구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

code-on-demand(optional): 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다
		          (ex_JavaScript)

**uniform interface**: HTTP 표준에만 따른다면 안드로이드/IOS 플랫폼이든, 
특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용할 수 있으며,
URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일

REST를 만족시키기 힘들게 하는 uniform interface의 제약조건 두 가지는 알아두자.

self-descriptive message > 메시지는 스스로를 설명해야 한다.
메시지를 봤을 때, 메시지의 내용으로 해석이 다 가능해야 한다는 것.

HATEOAS > 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다

これらのRESTの制約条件に従って作成されたAPIをRESTful APIと呼ぶ.
[ソース]Youtube video Day 1.2-2そんなREST APIでいいですか?

RESTの目標は？

구성 요소 상호작용의 규모 확장성(scalability of component interactions)
인터페이스의 범용성 (Generality of interfaces)
구성 요소의 독립적인 배포(Independent deployment of components)
중간적 구성요소를 이용한 응답 지연 감소, 보안 강화, 레거시 시스템 인캡슐레이션 
(Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

明かりがついているそうで、わかりやすいです
それぞれのリクエストがどのような動作や情報のためであるかは,リクエストの様子そのものから推定できる.

RESTのメリットとデメリット

장점: 
1. HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API를 위한 별도의 인프라를 구축할 필요가 없음
2. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줌
3. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능
4. Hypermedia API의 기본을 충실히 지키면서 범용성을 보장함
5. REST API 메시지가 의도하는 바를 명확하게 나타냄
6. 서버와 클라이언트의 역할을 명확하게 분리함

단점:
1. 표준 자체가 존재하지 않아 정의가 필요함
2. HTTP Method 형태가 제한적임(사용할 수 있는 메소드가 4가지에 준하니까)
3. 브라우저를 통해 테스트할 일이 많은 서비스라면, 쉽게 고칠 수 있는 URL보다 
   Header 정보의 값을 처리해야 하므로 전문성이 요구됨
4. 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많음(익스플로러 등)

必ずRESTについて行かなければなりませんか?

RESTを作るRoy T.Feildingではないそうです
RESTは単純オブジェクトアクセスプロトコル(SOAP)に比べてそれほど複雑ではなく,ルールは少ないが,それぞれが困難である.
[ソース]Youtube video Day 1.2-2そんなREST APIでいいですか?

Reference

https://ko.wikipedia.org/wiki/REST
http://www.incodom.kr/REST
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://jy-tblog.tistory.com/24
https://www.youtube.com/watch?v=RP_f5dMoHFc Day1, 2-2. そんなREST APIでいいですか?
https://www.youtube.com/watch?v=iOueE9AXDQQ REST APIとは何ですか?
https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest
SOAPとRESTの比較