ウェブAPI設計ちょっとだけディープダイブというところでちょっとだけディープダイブウェブAPI僕らはバックエンドエンジニアなので作ることいろいろあるかと思うんですけどもめちゃめちゃありますめちゃめちゃありますよねAPI

ザ・グッドパーツでしたっけAPIザ・グッドパーツはいスネークのそうそうそうオライリーでトップ3に読みやすいあの本読みやすいですねあれは読んだんですが実践してみるとねこれなんだどうしたらいいんだみたいな際どいやついろいろあるわけなんですよ確かにあれベーシックプラスちょっと実用みたいな実際にプロダクトやるときの考え方みたいなところ多いっすねそうですそうですそうです

実際にやってみるといろいろなんかイレギュラーパターンみたいなのがあってそういうのにもやっぱ対応してできるようになるべきだと思うんですよ中期エンジニアは間違いないなので今日はそのAPIのなんか超基礎を乗り越えた人に対してもう一歩踏み出すみたいな

そんな話ができればなと思いますなるほどこれこそが本当に中級への道というわけですかねそうですそうですそうです今日は種本というか元ネタはGoogleのAPI設計ガイドラインですそれ最上級じゃないですか最上級ではないGoogleのですねドキュメントの紹介なんですけどGoogleってみんな知ってる

大正義企業大正義企業そんな海軍みたいなことある大正義企業海軍みたいなもんですよ本当にねグーグルのアルファベットの旗打ち抜いた瞬間多分バスターコールですよ戦艦何台だっけあれ分かんないけど地球上の生物何回死ぬみたいな分かんないですけど大将一人来るからね来ちゃいますから怖いね

ちょっと対象に寄せんなはいでGoogleっていろんなドキュメントとかGoogleのノウハウ公開してるんですよ今回のAPI設計ガイドラインもそうですしJavaScriptのコード規約とかありますよねPythonとかもコード規約ありますしあと僕好きなのは好きなのは好きなドキュメントがあるんですよ好きなGoogleのドキュメントなんじゃそれリワークだっけな

生産性の高いチームを作るための実験をいろいろやった結果心理的安全性が一番寄与しますっていうのをヤンヤン プロジェクトアリストテレスの副産物ですか深井 そうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそう所以121212121212121212121212

なのでねすぐおすすめなんですがそんないろんなドキュメントの中で今日はAPI設計ガイドラインでございますおー設計ガイドラインはいちょっとこれ乗り越えられるかな乗り越えられるものをピックアップしましたありがとうございますでたくさんあったんですけどはいまあ分量としては多分1時間ぐらいで読めるぐらいかなおー

いろんなパターンがあるんですけどその中でキャッチーそうなやつですねちょっと3つぐらいピックアップしてきたんで気になったなと思ったらぜひ元のドキュメント読んでみてくださいなるほどなるほど設計ガイドラインっていうのは要はエンドポイントこうやって作るといいあるよってことそうですねなのでシステムの構成とかではなくウェブのURI

こういう風な名前にしようねとかみたいな話ですなるほどまず最初第一歩おさらいからいきましょうかリソース思考のレストフルAPIみたいなところでドベーシックを言うとウェブAPIを思い浮かべていただけるとどんなものかなというと例えば

ユーザーズというリソースに対してゲットだからどうしようかなひまプロ.ネットっていうドメインだとしましょうひまプロ.ネットスラッシュユーザーズでゲットをするとひまプロ.ネットの利用者の一覧が取ってこれるとなるほどねうん

イメージつきやすいですよ多分そうですよねゲットは取得ですあとは作成新規登録ポストリクエストでひまぷろ.netのユーザーズにリクエストをするとユーザーを新しく作れます作りました新しく作ったやつを取得するっていう順番にすればよかった最初取得しちゃった

あとは更新ですね更新アップデートとかですけど例えばPUTとかPATCHでさっきのひまプロ.NETユーザーズのその下のIDを指定したいのでスラ1とかですねID指定しないと全員更新されちゃうよってことですよねはいそうですねあるんかなそんなことないよね多分ね普通ないユーザーズスラ1でアップデートでもありえるかもしれなくない

何も設計知らずに作ったらもしかしたらログインしてるからログインでID取れるしURLには載せなくていいかって思う人はいるかもしれないトークンで特定してるってことですねあるかもしれないが一般的なIDですと驚き最小の原則的には驚いちゃうぞっていうところですよね多分そうです

更新はPUTとかPATCHリクエストでやりますと最後に削除デリートですねデリートもFUJIMA PRO.NETユーザーズ1で一番のユーザーが

消されますとみたいなのがリソース思考のリストフルAPIでした基本的にこれで乗っ取ってやっておけば割としっかり作れるよっていう感じですよねシンプルで分かりやすいものがシンプルで分かりやすいはいっていうので今のは作成、取得、更新、削除の4種類紹介させていただきましたクラットってやつですねクラットってやつですで、ここからGoogleの話ですGoogleの中で標準メソッドというものを定義してますと

標準メソッド標準メソッドメソッドって言ってるのはhttpメソッドではなくメソッドっていう言い方をしてますなるほどそれはさっき言った作成取得更新削除英語で言うとgetcreateupdatedelete順番間違えたgetってかreadだcreatereadupdatedeleteそれにプラスgoogleはlistっていうのを

つけてますこれは名前の通り一覧表示ですねなのでさっきで言うひまぷろ.netユーザーズのゲットはリストっていう標準メソッドに割り当てられると一見の取得とリストの取得を分けてるわけですねはいGoogleを分けてます

っていう考え方あるんだなっていうのがまず1個ですねここからが本編ですこんなパターンあるんだなをいくつか紹介させていただきます大きいやつ2つわちゃわちゃっていうのを2つって感じですなるほど4つまず1つ目カスタムメソッドでございますカスタムメソッドカスタムメソッドというのはさっき紹介したクラットプラスリストこれ標準メソッドなんですけどこれ以外にも

なんか欲しいぞっていう時カスタムメソッドを使います例えばあれですか権限不要みたいなそういうのですね多分権限不要もそうですし具体的な例として出てたのは以前エピソードで出てきたサーチとかサーチね確かにあれ取得とかリストとはまたニュアンス違うかもしれないあとは非同期的に処理するものに対するキャンセルとか

キャンセル?はいなんかめちゃめちゃ処理に時間がかかるAPIがあったとしてその処理途中で止めたいぜっていうリクエストを出すみたいなキャンセルとかあれもかなGmailとかって送った後にさなんか取り消すみたいなやつあるじゃないですか送った瞬間あれキャンセルメソッドで作られてるんじゃないですか

知らないんですけど多分そうじゃないですか知らなかったあんまりGmail使わないかGmailはあります裏どうなってるかは知りませんそういうことですねっていうのでそういうイレギュラーなやつを使うときにカスタムメソッドを使うといいですよという話をしてますでカスタムメソッドと言ってもHTTPメソッドって限られたものを使うしかないですねですねゲットポストプットパッチデリートこういうときって何割り当てるんでしょうねっていう

それはポストじゃないですかそれどういうどういう心持ちですかなんかポストってそういうのに使われやすい気がするんですよ例えばですけどえーっとゲットとかってさリクエストパラメータの限界あるじゃないですかURLに載せれる文字数の制限でうんうんうんとかでなんかパラメータあまりにも多い時にポストになったりとかうんうんうんあと

あれですねウェブの本当にウェブシステムとかだとフォームにゲットとポストしかないからプットとかデリート使わずにポストを使ってパラメーターでどのメソッドなのかってのを送ったりすることがあると思うんでその系譜を引き継いでとりあえずポストにしとけばびっくりしないんじゃないかなっていう素晴らしい

素晴らしいでございますGoogle入れるかもなそれは自信すごいなそれは自信すごいですがもう素晴らしいです基本的にはポストが無難ですねこの設計ガイドラインとしては基本的にはポストを使いましょうただゲットでもいいよとただゲットでもいいときには条件がありますとそれは副作用がないことですもう少し優しく言うと普段

ウェブAPIでゲットとポスト使うかと思うんですけどそれぞれどういう時に使うかっていうとゲットはあくまで取得ポストは何か作成をする時ですよねリソースの作成そうするとゲットっていうのはただ取ってくるだけなんでバックエンド側例えばデータベースって別にゲットする以前と以後って全く変わんないんですよそれを副作用がないとか何回同じリクエストやっても同じものが返ってくるべき等性があるっていうんですけどはい

そういう普通のゲットリクエストと同じように副作用がないべき等性があるときにはゲットを使ってもいいんじゃないっていう風にはGoogleは言ってますなるほどねただカスタムメソッドを使うときってだいたい副作用があるんでサーチはちょっと別かもしれないですがなのでポストを使うのが無難ですって言ってるのがGoogleの見解でございますなるほどべき等性と副作用は結構

出てきますよね結構出てくるですよねゲットはデータベース変えないし何回やっても同じだからべき等性あるあるかつ副作用ないない

フットはどっちもあるそうそう思うなるほどだから別物ですよね一応別物別物はいでまあそのリクエストに含められる情報量もゲットってクエリパラメーターだけでポストはボディが使えるんでポストの方が無難はいこれがまずhttpメソッドの話ですはいであとはグーグルが言ってるのがその

カスタムメソッドだよっていうのをどう表現するかそこだよねこれはGoogleの中で設計ガイドラインっていうぐらいなんでルール化されてますどうやるかっていうとURIの末尾にコロンでカスタムメソッド名を付ける

URLの末尾にコロンだから例えばユーザーに対してさっき言ったサーチをかけようと思ったらひまぷろ.netスラッシュユーザーズコロンサーチポート番号みたいな見え方しますけどねコロンでカスタムメソッドをつけるようにしますっていうのがGoogleの設計ガイドラインに書いてるものでした見たことないかもしれないコロンでそう思うクエリパラメータより前に来るんですか

クエリパラメータより前に来ますねその後にクエリが来るんで試しになんか見てみようかな今先ほど言っていたカスタムメソッドの実際の使用例ないかなって頑張って探してましたがGmailとかGoogleドライブでサクッとそんなの見つからないかなと思って見たんですけど探せずとりあえず頑張って見つけたのはGCPのSDK

そっちかーGCPGoogle CloudのSDKのファイルを移動させるとかの時にポスト使って末尾にムーブのカスタムメソッドでやってたりするのはありますねそっか移動も確かに

既存のメソッドでやろうとするとむずいなプットとかパッチになるんですけど多分ただ分かりづらいよねっていうところなんですよねリソース自体が変わってるわけでもないしそうそうそうっていうのが一つカスタムメソッドでしたもうこんな時間経ってるんですね次いきます次

リストのページ分割ですリストのページ分割はいこれはねよくあるっちゃよくあるんですけどめちゃくちゃありますねさっき言ったGoogleの標準メソッドのうちのリスト一覧を取ってくるやつですがこれはページ分割をするべきですとうん

言ってる意味はどういうことかというとリソースが1万個ありますって言った時に1万個ドーンって返すんじゃなくて50個ずつとかそういう風にページ分割をして返すようにしましょうねっていうですよねそう思いますGoogleがもう一個言ってたのは分割する必要ないなこれっていうAPIもあるわけじゃないですか

例えばユーザー収容数が最大で20のシステムでユーザー一覧を返すときページ分割する必要なさそうだなって思うわけじゃないですかしろって書いてます最初からしろと最初からしろとなぜならページ分割をサポートしてない状態から後からページ分割をするとAPIの動作に一貫性がなくなりトラブルの元になりますとなるほどねなので最初から

ページ分割できるような作りにしとけとこういう場合はどうですか都道府県のリストを取得したいとか

都道府県ね都道府県はいらなそうですね確かに増えないよね増えない増えないゼロじゃないけどその時はもういろいろそれどころじゃないから何か大きな何かがあったよねそうそうそうそれ時はもうそれどころじゃないから確かにそれはそうですね都道府県一覧も取ってくることあるかあるな確かに確かに何でもかんでもじゃないですねそうするとね増えるものは何かっていうのを

考えてページ分割しましょうなるほどページ分割するときに分割の仕方についてもちょっと研究がされててページサイズとページトークンというものを設定しましょうという風に書いてましたちょっと分かってません僕はここは

なるほどページサイズは分かります何ページあるかってことですか全部でページサイズは1ページ何件取ってくるかですねそっちページサイズって言うんですねページトークンはそのページ1ページ目2ページ目3ページ目のページを表す文字列っぽいですなんで次のページトークンはこれですっていうのを示すことで特定のページだけ取ってこれるようにしましょうねみたいなことが

書いてましたえ、なんで数字じゃダメなんですかねこれあ、す、ごめんなさい数字でもいいです数字でもいいですごめんなさいごめんなさいえ?てかなんなら数字でしたあのね123456っていうそういうやつそうですそうですあーはいはいそうですそうですあーなるほどなるほどそれをページトークンと呼んでるわけだページトークンと呼んでますねなるほどねはい

特定のアイテムリストみたいなページを1位に指定できる数字値この辺を考慮してページを分割しましょうというのが2つ目でしたなるほど

残りお二つお付き合いくださいこういうのあるんだなの小技二ブロック紹介します一つ目部分レスポンスです部分レスポンスこれは何かというと一つのリソースに対してアクセスしたときに情報まるっと返ってくるのも困るので一部だけ返してあげようという設計パターンでございますあれですかデッキからカード一枚引いたらエクゾディアの左腕だったみたいなことですかそういうことかなぁ

どういうことだろうあのちょっと普通に具体例で言うとユーザーズ1でゲットするときにうわぁ住所とかいらねー名前だけでいいっていうときに名前だけ返してくれるようにするという設計パターンなるほどね

ちょっと質問いいですかそういうのってやろうとしたらグラフQLになるのかなっていうイメージがすごくあるんですけどRESTでもRESTというかAPIとかでもそういうのやるんですかはいみたいですねグラフQLが得意とする領域ですよねグラフQLが標準で備わっている機能ではあるんですけどそれをRESTでもやっちゃおうっていうのがこの部分レスポンスです

具体的にどういう風なURI設計にするんだろうっていうところなんですがGoogleのガイドラインを見るとクエリパラメータでfieldsサッカーフィールドのフィールドの複数形でfieldsイコールリソース名.valueだからユーザーのネームだったらfieldsイコールユーザー.nameっていうクエリを加わせると特定のユーザーの名前だけ返す

っていうエンドポイント設計にするらしいですねめちゃめちゃいいかもしれないきっとそれがいいかもしれないってなって発明されたのがグラフQLかもしれないネットワークのトラフィック小さくできたりしますからねこれによってね一方で僕非常に思ったのがテスト大変そうだなと思いましたまあ確かに全部やらなきゃいけないの多分これは普通に単体でぶっ壊れ売るから単体でぶっ壊れ売りますね

これはあのだってAPIの標準機能で多分ないと思うんでAPIって言ってんのはフレームワークかレイルズとか標準機能であるものじゃない気がするんで多分ちまちまやると思うんですよある程度でもあれじゃないですか全件取得と一件取得できたらなんか大体ぶっ壊れなさそうじゃないですかネームなんでネームもだしアドレスもだしえー

言ってる意味分かりますかねそうだから全部のパラメータ振ったやつを1個テストしてあとは単独で取れるかどうかチェックしたらなんか壊れなさそうじゃないですかそう思いますそう思いますそれをいちいちやらなきゃいけないなと思ってベストイペイだったら1回で済むじゃないですかダーンってやって1個返ってきたらよしって感じですけどこれは各バリューごとにやらなきゃいけないんでなるほどねいやこれちょっとめっちゃいいかもしれないでもいいですよねこれうん

このパターンあるんやが1個目このパターンあるんやその2サブコレクションのリストっていうところでサブコレクションのリストね知ってそうな雰囲気出してる知ってそうな雰囲気だけこれはですね僕こういうのあるんだっていうシリーズでサブコレクションって言ってるのは

例えばAmazonを思い浮かべてもらってユーザーズの中の欲しいものリストはいはいはい欲しいものリストがサブコレクションですなるほどねユーザーズの下のやつ入れ子になってるやつねありえないんですけど全ユーザーの

欲しいものリストを一括取得したい場合それURI設計どうするんでしょうというのがこのサブコレクションのリストですそういうことかはいはいはいはい

で全ユーザーの欲しいものリストを取ってくるとき多分ユーザーズユーザーID欲しいものリストっていうURLになると思うんですけどユーザーズの後のユーザーIDを表すところにハイフンを入れるユーザーズハイフンユーザーズすらハイフンすら欲しいものリストで全ユーザーの欲しいものリストを取って

ハイフンの後すぐスラッシュ入るんですかそうです直感的だとアスタリスク入りそうじゃないですかそういうのってそれこそLinuxのファイルシステムでここのディレクトリのファイル全部取ってくるときってアスタリスクつけますけどアスタリスクはURLのエスケープが必要だったりするんでGoogleはそれをスラッシュじゃないごめんハイフン

ハイフンで表現しているともう一回フルのパス聞いていいですかはいひまプロ.ネットのユーザーの欲しいものリスト全部取ってくる場合ひまプロ.ネットすらユーザーズすらハイフンすら欲しいものリストっていう複数指定したいところにハイフンを入れるイメージですねなるほどね

アスタリスクの代わりにあーそっかそうなるかアスタリスク?アスタリスクって言ったのは僕が勝手に言ってるだけなんですけどアスタリスクってワイルドカードガチじゃないですかワイルドカードに使いがちそれってなんかこう3階層になってて真ん中なんでもいいよみたいなそうそうそうそうその通りですサブコレクションのリストってでもなんかあれですよねユーザーズとリストがあってそのユーザーズのリストがバババババって並んでるってことですよね

ユーザーズのリストがはいそうですそうですファイルシステムとはちょっと階層が違うような気がするそれはそうかもしれないですねそれはそうかもしれないスラッシュじゃなくてハイフンを入れることで複数のリソースを横断的に取ってくるみたいな設計パターンがあるみたいっていうのが2つ目こういうのあるんだなこれ直感的に

考えるの難しいななんかちょっと具体的なユースケースもちょっと僕はよく分かってないんですけどこういうのあるんだっていうまあ確かに具体的なユースケースも今パッと思いつかないそうなんですよね管理画面とかだったらなんかありえそうだけどはい最後こういうのあるんだな最後ですリクエストの検証というものでクエリにvalidate only イコールトゥルー

っていうクエリを設定したときにAPIはポストリクエスト例えば受け取る副作用があるリクエストを受け取ってバリデートオンリートゥルーのときリクエストパラメーターの検証だけやって何もやんないでパラメーターが合ってるかどうかだけ返すっていう設計パターンがあるらしいですいつ使うんだそれ

それ非常に難しいですよね普通に400返せばいいんじゃねって思うんですけど僕は多分多段処理があるんでしょうね分かんないですけど途中で処理が終わってしまうとものすごく不都合があるリクエストというかAPIかなんかがあって絶対クエリ間違えちゃいけんぞみたいなAPIがあったとして事前にバリデートオンリーで

リクエストしてそこ通った後だけリクエスト出せるようにするほうとかなのかなと想像しながら読んでましたわーなんかこれいつ使うこと一生使わなそうな気もするし

間違えたら使うときこの時かって気づくときも来そうな気もするしこれ使わなきゃってなった瞬間APIの設計見直した方が良さそうだなって僕は思いますけどね確かにねただこれはこういうのあるんだなっていう共有なんでこれだって思ってもなかったでしょこんな選択肢ないGoogleのAPI設計ガイドラインの中であったってことは多分使ってるんだろうなと思います何かでなるほどね不思議ですね最後こういうのあるよねーです

こういうのあるよね3つ1つ目大きなペイロードというのでレスポンスがでっかいときどうするんだとレスポンス?そうですね多分基本レスポンスじゃないかなペイロードってリクエストに使うイメージあるんですかリクエストかなリクエストを送ったときのボディのところをペイロードってよく言うイメージあるんですいません曖昧ですググります

送受信なんでどっちもですね多分あーどっちも使うんだ僕は勝手にレスポンスの時でかくなるだろうと思ってたんですけど確かにリクエストの時もありますねなんか画像送ったりする時とかででけえペイロードがある時どういうAPI設計にすべきでしょうかというので基準値としてはネットワーク層は32MBがリミットらしいんであーそうなんですか一般的にはどうやら10MBを超えるペイロードはでかいと言われると

10メガもでかいですよねかなり動画アップロードするときとか分割されてるんですかそこなんですよそこなんですよねそういうでかいペイロードするときには選択肢素直にやるのは良くないですなんならできません32メガがリミットなんでそこで選択肢が2つあります1つ目

まず一つはストリーミングにする非同期処理二つ目別の方法でアップロードダウンロードするようにする別の方法ストレージか何か例えばGoogleドライブとかS3とか分かんないですけど普通のAPIリクエストじゃなくてそっちを経由してシステムとやり取りをするこの二つの選択肢を取るようにしましょうという風に書いてましたそっちに送るリクエストはペイロード大きくてもいいんですか

そうなんそれはそうか確かにただどうなんだろうなそういうことですその何でしょうAPIサーバーと直接やり取りすんなっていうその何でしょう例えば4ギガの動画上げるときってすぐ200返ってこないじゃないですかそれってユーザーエクスペリエンス良くないし何ならセッション切れるんじゃないかな多分

なので非同期処理にしてストリーミングとか別のところにアップロードするような非同期処理にしてリクエスト受けたまったぜっていうふうなやり取りにしましょうっていうのがこの大きなペイロードっていう一つ目でしたストリーミングっていうのは普通のリクエストと比べるとずっと接続をつなぎ続けてその出来上がったパイプにドバドバドバドバデータ流していくみたいなイメージですかそうです

僕はそのイメージです正直そのAPIガイドラインに具体的なやり方は書いてないんで分かんないんですけどストリーミングって書いてたんで僕はそのイメージをしました多分あれですねHTTP2とか3にあるやつですねそうですねやったことはないんですけど同じく1つ目2つ目並び替え順序っていうのでこういうのあるよねの2つ目ですありそう並び替えリスト標準メソッドのうちのリストはオーダーバイとかで並び替えできるようにしましょうとはい

だよねと思ってこれもね標準でついてるものがあったりするんですよ例えばDジャンゴじゃなくてジャンゴジャンゴだとオーダリングっていうクエリかがデフォルトで使えるようになったりするんですよオーダリングイコールネームとかにすると名前順に変わったりとかイコールIDとかにするとID順に

並べ替えしてレスポンス返したりとかするそれ自分で実装しなくていいんですか不思議なんで確か標準機能だったはずなのでリスト返すときは順序並び替えれるようにしてあげるとフロントエンドの人に対して優しいです最後3つ目リクエストの重複ですこれはですねまずAPIというものは基本的にべき等性を担保すべきだというのがまずGoogleさんがおっしゃってます

ただリソース生成系はそうはいけませんよねとそうですねそんなイメージありますよねさっき言った通りひまわプロ.ネットユーザーズにポストをするとユーザーができるとデリートしたら消えますしねこのユーザーズにポストをしてると1回目リクエストしたらユーザー1ができて2回目リクエストしたらユーザー2ができるとこれは何回違う2回リクエストすると2回でも違うやつが返ってくるべき等性がないじゃないかと

なるのでべき等性を担保しようと言っておりますどうするか成功したら成功したよっていうリクエストを返すNOそうなんですけどリクエストIDリクエストIDと一緒にリクエストしましょうという風に書いてますリクエストID例えばですよポストでユーザーズでボディとかにリクエストID1でリクエストしてユーザー1ができましたと

でもう一回リクエストID1でユーザーズにポストするとそうするとそのリクエストIDで作ったリソースもあるでって返してくれるとレストからちょっと外れてるあーでもそうなのかなレストってポストの時にさIDつけんなよみたいな感じじゃないですかあー確かにレストからちょっと外れてますすごいはいGoogleのAPIガイドラインではその

べき等性を担保すべきだっていう哲学のもとUAIDみたいなものをつけてべき等性を担保しましょうと言ってますこれはどういう考えかっていうと重複したリクエストを送ってきたってことはクライアント実は前に返した成功したよ作ったよっていうレスポンス受信してない可能性があるとうん

だったらそれもう作ってたよって言ってあげた方が親切だよねなるほどねっていう考え方ですねこれは非常に僕は分かるんですよ無駄なリソースできないんでどうやって裁判するのっていう不思議はあるけどねリクエストIDをログインとか分かんないですけどその段階で多分渡すんでしょうねもしくはクライアント側でどうするんだろう確かにトークンか何かなんか

トークン無難そうですよねGoogleほどの巨大なサービスがそれを衝突させずに管理してるって思うと泣けてきます泣けてくるそれは泣けてきますっていうのがこういうのあるよねで大きなペイロード並べ替え順序リクエスト中の重複っていうところで紹介しましたいろいろ言ったんですがGoogleのAPI設計ガイドラインの中のごく一部お話しさせていただきましたがこういうのあるなっていう

なんかちょっと自分の中のコンフォートゾーンちょっと出たっていう確かにそれ便利じゃんっていうのがいっぱいありましたねそうですよねそういう体験をしてもらえるとありがたいなと思います今はもう一気にのりさんに向かって喋ってたんですけどリスナーの方もぜひ何かの気づきになってもらえたらなと思いますそうですねフィールド使いますフィールドをねマイナーチェンジした微妙な

エンドポイント作ろうとしてでもなんかだいたい同じような名前のリソースになっちゃいそうだから変なマイナーチェンジ重ねてキモいAPA作ったことありますねそうなんですねそういう時にいいかもしれないですね確かにフィールズとかだよね

ぜひ気になった方はGoogleのAPA設計ガイドライン見てみてくださいそんな長くないんで1時間半とかで読めるんじゃないのでもね今日これを聞いたことによってねある程度事前知識が備わってますから確かに確かにマジで55分で読めるんじゃないですかね全部見ると多分20個ぐらいあったかなこういう僕が今紹介したやつの今日は332だから8個言ったんですけど20個ぐらい

あるなーっていう印象ですうんうんうんうんまあ面白かったんで見てみてください素晴らしいです今後はあの別のドキュメントもガンガン紹介できればと思うのでおーあのね元ネタの宝庫ですGoogleのドキュメントあそうなんだおもろいそうなんだうんすごいわちょっと積極的に読んでいきますはいはい

というのでハッシュタグひまじんプログラマーをつけてツイッター等でフィードバックいただけますと我々のモチベーションにもなりますし番組のブラッシュアップにつながりますので気軽にどしどしお願いいたしますはいお願いします説明欄にGoogleフォームのURLがありますこちらからお便り聞きたいこと相談したいこと何でもかんでも募集してますのでそちらもお願いしますはい送り放題ですこちらはいはい

今ならなんと送り放題です期間限定でねしかも無料このエピソードを聞いているあなた1時間以内なら送り放題です1時間1分経ったらどうなるんですか送り放題じゃないです聞き直してくださいこのエピソードそしたらリセットされるんでねというわけで今回ここまでで終わりますバイセコ初めて触ったMacBook

各種ポッドキャストで配信中