※この投稿は米国時間 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 をその基盤
GraphQL Caching について | Akamai Japan Blog
コンピューティング あらゆるワークロードに対応した VM により、構築、リリース、スケーリングを迅速に実行
「参照系はGraphQLだけど、更新系はRESTでPOSTにします」みたいな意見を稀によく見る。 もちろん何かしらのトレードオフを考えてRESTを選択しているのだとは思うのだけど、GraphQLのmutation(要は更新系)を誤解している人も中にはいるのではなかろうか。 先日GraphQLのmutationは難しそう……という意見をもらって、詳しく聞いてみるとmutationについて誤解があるようだった。 もしかしたら同じような勘違いをされている方は他にもいるかもしれないなーと思ったのでまとめておく。 あーそれは多分誤解があるような気がしますね！mutationの方は投げるクエリを変えることで、動的に更新対象を変化させる……みたいなことは志向していないと思います。 ここの例のsetMessageをみてもらうと分かりやすいかと！https://t.co/Jq08v5n4x6— すーさん二号
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
