API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤
REST API における同時並行制御 - 理系学生日記
以前「API で同時に更新要求があったとき、どうするのが定石なんだろう」というのを調べたのですが、きちんとまとめていませんでした。 それからちょっと時間がかかってしまいましたが、簡単にここでまとめてみます。 取り組む問題 勧告 概要 実現 Etag Precondition 補足 参考 取り組む問題 更新系の操作を行うとき問題になるのは、1 リソースに対して同時並行的な更新が行われようとした場合です。 たとえばですが、 A が口座の貯金額を参照し、$100 あることを確認する B が口座の貯金額を参照し、$100 あることを確認する A が $100 に対して $10 を追加し口座を更新する B が $100 に対して $1 を追加し口座を更新する (結果として、A の更新が失われてしまう) これでもし 3. で行った A の操作が失われたとしたら、それは大きな問題になります。いわゆる L
HTTPクライアントとして使うjersey-client
JAX-RSのリファレンス実装であるJerseyには、RESTサービスを提供するサーバ側の実装（jersey-server）と、RESTサービスを利用するクライアント側の実装（jersey-client）とがあります。 RESTサービスではHTTPを介してサーバとクライアントとがやりとりしますから、当然jersey-clientはHTTPクライアントの機能を備えています。今回はJerseyの使い方の番外編として、RESTサービスを抜きにHTTPクライアントとしても、jersey-clientは使い勝手が良いという話をします。 ちなみに、JAX-RS 1.1にはクライアント側のAPIは定義されておらず、今年（2012年）のQ2にリリース予定のJAX-RS 2.0から定義されることになっています。（本稿執筆時点ではEarly Draft Reviewの段階） まず使ってみる 何はともあれ、使っ
RESTに関する３つの間違い
楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
