概念を削り込んでいったらここまで来てしまった
RESTful API
GraphQL
RPC
gRPC
browser Workers
プログラムから見た外部へのアクセス界面
自由な形式は混乱を産むから、賢いスタイル/形式が考案されてきた
RPC
ローカルに関数を呼ぶのと同様に、別の計算機に対し、関数名と引数を渡せば良い、という設計思想
// 通常の関数呼び出し const local_result = localfunc(arg1); // RPCの理想像 const remote_result = remotefnc(arg2); // RPCの実像 const rpc_result = rpc(remotefnc, arg3);
理想像が使えたら最高である。しかし、現実には解くべき問題が無限にある。
funcのバージョンはどうやって指定する？暗示的？Arg1？
argの型制限は？ named argは？ 可変引数は？
通信プロトコルは？ TCP+独自？ HTTP？
遠隔計算機の指定方法は？
APIは各言語ごとに用意しなきゃいけないの？
ああああああああぁぁぁぁぁぁ
gRPC
より良いRPCを目指す形式。
RESTful
Webの世界で、よいClient-Server APIを目指したスタイル (規格ではない)
RPCのような手続き/関数中心の考え方ではなく、リソースが中心。
リソース/Entityがまず定義され、そこにURL/URIが割り当てられる。
リソースに対する操作がHTTP Methodsで規定され、アクセスする。
リソースがさき、レスポンスはあと。
GraphQL
Webの世界で、
| name | partial query | one query | cache | monitoring |
|---|---|---|---|---|
| GraphQL | built-in | built-in | ||
| REST-Swagger | with query (fields param) | with good scheme | ||
