この番組は駆け出しエンジニアの順平と先輩エンジニアの海一則が送る 駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオですということで本日ですが日本全国のバックエンドエンジニア いやバックエンド触ってるエンジニアに届けたいん?世界全部ってこと? あーすいません日本全部日本全部?ちょっとさすがに日本語なんで はい150回ぶりの

web api エンドポイント設計選手権でございます 150回ぶりですかこれだいたいねターニングポイントぐらいの感じだターニングポイントってか折り返しぐらいのはいだ前回148回やったんですけど これが何回かわかりませんが多分300超えてますよ300超えてるんですよねで前回は結構優しいことやったんですけど 順平もまあまあ成長してきているということではい

現場で何か発生するちょっとイレギュラーを含んだ感じのエンジニアの腕の見せ所が問われる感じのクイズやっていこうかなと思います緊張するこれはいしますよね今回のパターンだと俺が緊張するわちなみに正解も正解か分かりませんなのでレベルも区切ってきたんですけど後半に関しては

まあ議論する感じではいいきましょう ok ですはいじゃあ早速サクサクいきますねおーまあ例題ですか例題例題例題例題例題ですまあなんでクイズ出すんでユースケースって言うんですかこういうこういうやつって言うのでメソッドパスあとパラメータはいクエリかもしれないしボディかもしれないはいでそれを言ってなおかつそのそれを設計をした気持ち

これを答えてもらうっていうやばいかもしれないじゃあまず例題ですユーザー一覧を取得するごめんなさい一個忘れたAPIのベストプラクティスとしてパスの中にバージョン番号を入れるっていうのがあると思うんですけどクイズなんで冗長ですと毎回言わなきゃいけないのバージョン番号なしでお願いしますはいじゃあ第一問レベル1ユーザー一覧を取得する

はいじゃあじゅんぺいからお願いしますこれ例題なんで例題の回答お願いしますユーザーの一覧を取得するはいメソッドはURLURLURLから珍しいですねだいたいメソッドからいくと思ってたじゃあメソッドからいきますゲットですゲットメソッドです

URLユーザースラーユーザーズとかでしたっけとかでしたっけってやめてもらっていいですかまとめて今スラッシュ2個連続出してたからさスラスラになってましたもう一回言い直してスラスラッシュそこじゃないんだけどスラユーザーズみたいな感じで言って

これで終わりにしますじゃあのりさんお願いします僕ゲットでユーザーズでクエリはなしでお願いしますクエリストリングですね多分URLの?なんちゃらがんちゃらみたいなはいなんで答えはですねゲットユーザーズですねゲットのスライユーザーズはいこれ例題ですここまでは多分前回のエンドポイント選手権ぐらいのレベル感かなと思うんですけどやべえ

ここから1ランク上げていきますねさっきのユーザー一覧ありましたけどユースケースをちょっと絞っていってですね1ページで20件表示するページがあるとしますユーザーの投稿ユーザーのブログでも何でもいいんですけど投稿一覧を20件表示するページがあってそれに使うAPIですその

2ページ目の20件を取得するみたいなものをやりたいんですけどどういうエンドポイントにしますかって伝わります?分かりましたよ2ページ目の20件を取得したいだから21から40件かなページは月ってことですねもちろん使ってる実際やろうとすると使ってるライブラリとかによって細かい命名とか形式が変わると思うんですけど

そういうのってどういうエンドポイントになる感じですかねっていう問題ですこれは前回からちょっとレベルが上がったというかどういう情報を渡してあげる必要があるかっていうところですねごめんなさいユーザー一覧って言ったんですけど忘れてくださいユーザーが管理しているブログ記事20件2ページ目21から40件目取ってくるやつゲットで

スラアーティクルズスラページ番号で終わりにしましたはいじゃあドリさんお願いしますはいまずメソッドはゲットでURLとかパスがスラポストにするかなはいクエリパラメータでページイコール2はいはいはいお渡してあと1点質問なんですけど表示件数は変わりますか変わじゃあ変えれるようにしましょう

であればもう一個そのページの最大数を指定するクエリをつけるかなという気もしました今言ってた2020件だったらそうですね20デフォルトにしてもいいけどなデフォルトにしようつまり何もつけない20件の場合は何もつけないはいはいはいでなんか表示件数を100件とかに変えるってなった時は

パワーページイコール100とか渡せるようにするかなありがとうございます出題としてはのりさん正解ですポイントはいくつかあります最初のアーティクルズとかポストは一旦どっちでもいいんですけど僕もポストかなって思ってたんですが一旦どっちでもいいです記事なんでで

その後に一般的なのはクエリでページとあとは取得する件数を送るのが一般的かなと思ってたりしますなのでのりさん言ってた通りクエリでページ2ページ目ページイコール2であとはパーページってのりさんおっしゃってましたけどとかサイズとかで何件取ってくるかっていうのを送ることによってバックエンドAPA側は

データベースにめっちゃあるうちの頭から何件取って送ればいいんだねっていうのを反転して返すっていうのがよくある形ですかねここで普通に一個相談というかのりさんとの話なんですけどデフォルトで20の時はクエリつけないかなみたいな話があったじゃないですかそうすると20の時だけの実装ちょっと変わるじゃないですか

とにかくページ数つけた方がコードちょっと短くなるんじゃないとか思ったりするんですけどその辺ってどうなんですかねこれは結構設計によると思うんですけどそもそも指定できる件数を

制限した方がいいかなと思うんですよねどちらにしろ例えばそこで1万とか指定されたらさすっごいでかいクエリ走って嫌じゃないですかなので例えば20件40件60件80件100件しか指定できないんだったらそういう指定をすべきだと思うのでどっちにしろそのチェックは必要かなという気がするのでそこにデフォルト値を持たせるかどうかで変わるからどっちでもいいのかなって気がしてましたうんうんうん

例えばちょっとポッドキャストを聞いてる人に分かりづらいと思うんですけど僕らが使ってる配信プラットフォームってエピソード一覧表示するときに件数指定できるじゃないですか多分20 50 100とかで指定できるんですけどその場合だとバックエンドAPIで20 50 100のどれかかなって一回バリテーション走らしてその件数返してるみたいな感じなんですかねかな?いいんじゃないかなデフォルトとかは

どうなっているのかな見てみますかデフォルト渡さなくても何かしら動いてほしいから渡さなかったとしたら難件とかっていう実装にはなっているでしょうね変なの渡してもデフォルトになるとかはありそうそうなっててほしいですよねそっちの方がみんな楽ですよね多分実装もだし予想外でしたなんで我々の配信プラットフォームはAmazonのやつなんですけど

クエリでID配列で全部羅列して取得してましたねブログの場合1から20みたいなオートインクリメントで振ってたらIDsイコール1、2、3、4みたいな感じで1個ずつ指定してる方式でしたねしかもIDsにカンマ指定とかじゃなくてIDsイコール1&IDsイコール2&みたいな感じで指定してましたねなんでだろうこれちょっと分かんないですけど

こういうのもあるとこういうのもあるという感じですねシンプルなのかなそれ裏側の実装がまあそれはそうかもしれないですね渡されたのだけ取ってくればいいしただこの何でしょう100件くらいないのかURLって上限の実はあるじゃないですかそういうのに引っかかる可能性があるっていうのが多分リスクとしてあるかなってあー確かに思っててでポッドキャストの今ID見てるとインクリメントされたやつじゃなくてなんかUIDみたいなのついてたじゃないですかうんうん

まあまあな桁数あるやつ まあでも100件ぐらいなら大丈夫っしょっていうあれなのかもしれないですねまあ要件的に絶対超えないし超えたとしてもそれいたずらだからいいんじゃないっていうまあそうですねそうですね うんはいちょっと脱線しましたがこれがのページングが伴う一覧取得っていう問題でしたはいはいはい次ちょっとこれやったかもしれないんで うん

やってたら言ってくださいうわそれ思い出せるかなユーザーのログインリクエストほうやってたとしてもやりましょうユーザーログインこれどうしますかメソッドはポストでパスがスラログインハテナユーザーイコールIDで送るボディえー

ログインページ書いたらわかるかも本当ですよねログインページ書いてみたらいいかいログインページを書いたらわかるかもしれないIDとパスワードを送るなんでIDなんちゃらとパスなんちゃらをそのまま送っちゃうとあれな気がしてるんですけど送っちゃいますクエリはなんか入れるんだっけ結局ユーザーなんちゃら入れるんだっけ入れ

はいOKですじゃあのりさんお願いしますはいメソッドポストではいセラログインはいですがアプリケーションによっては複数ログインがありそうな気もするのでそういう時はもしかしたらちょっと階層を作るかもしれない例えばアドミンセラログインみたいなユーザーズセラログインみたいなとりあえず今回はログインしますでボディでまずユーザーのIDユーザーIDと

パスワード送りますあとポストなので多分これは問題とは関係ない気がするんですがCSRFトークンを送りますぐらいじゃないかな以上ありがとうございます問題としてはのりさん正解でございますじゅんぺんのやつで明らかに間違えているのはボディでID送ってるんだからパスにIDいらんやろっていうところが明らかにいらないところですかねなるほどね

あとはこれは参考なんですけど結構調べてみるとスラオースっていうログインログアウトをひっくるめるパスを階層で分けているのがどうやら多そうですね

オーススラログインとかそういうことオーススラログインオーススラログアウト確かによく見るかも認証周りのやることをまとめたパスの階層を作るという感じですねボディはのりさんおっしゃってた通りIDとパスワード入れればよくてじゅんぺいがさっきそのまま送ってうんぬんかんぬんって言ってたのは普通はネットワークレイヤーで多分暗号化することが多いかなと思いますhttpsにするとか

DBにはそのまま保存しないでバックエンド側でハッシュにして平文そのままDBに保管しないみたいなねそういうことをやるのが多いかなと思います次レベルが上がってるか上がってないかちょっと際どいんですけど際どいやついきますユーザーのパスワードを更新するリクエストなるほどユーザー設定からパスワード変えると思うんですけどパスワードはバズワードだけ変えるタイプ

ですね物によっては登録アドレスとパスワードとユーザー名一気に変えるアプリとかあると思うんですけど今回はパスワードしか変えれないようなアプリなるほどでウェブサイト上で全部完結するタイプのやつあそうそうだから変にメール送られてそっからリセットのURLが発行されてとかではないではないポンで変わるやつじゃあ一撃で変わる一撃で変わるメソッドプットパス

スラユーザースラアドミンボディパスアップデートするパスパスパスパスワードパスが大好きでよくわからないボディにアップデートするパスワードはいおさらいするとプットスラユーザースラアドミンでボディにパスワードはいじゃあのりさんお願いします

そしたらパスワードで、Put requestの、そしたらパスワードで、ボディで古いパスワードを、オールドパスワード、いやまだオールドじゃないか、カレントパスワードと、ニューパスワードと、ニューパスワードコンファーメーションを送りますかね。リセットもしなきゃいけないですよね、今回ので。リセットというかパスワードの変更?リセットって何ですか?あ、いやなんか、

そのページに来た段階でパスワードリセットされてて新しいパスワードだけを設定するみたいなのじゃないですよねはいパスワード忘れたらみたいなこと言ってます?はいうわ考えてなかったパスワードが忘れたらいやでも今回のは普通にログインできてる状態でそうですそうです普通に変えたらだからそうですだからやっぱりオールドパスワードとニューパスワードとニューパスワードコンフォメーションが必要かなと思いました

ありがとうございますじゃあこれ問題出す側もクソむずいんですけど多分どっちも明らかに違うところがあるかもしれないと思ってて多分ちょっと順平の方からいきますputすらuserすらadminでパスワード送ってるんですけどこれは一体何を変更すればいいんですかって話ですねどのユーザーの何のパスワードを変更したらいいかわからなくなってるはず

なのでそれが特定できるようなパスになっている必要があるですねあとはスラユーザーの下のアドミンってちなみにどういう気持ちのアドミンですか気持ち的には各ユーザーは自分のパスワードしか変えられないですよっていうそこの自分のパスワードに対する権限を持っているというか他の人は変えられないから

そいつしか変えられないですよっていう意味のアドミンでしたなるほど多分その考えは大事だがおそらく認証済みで認証時に発行されるトークンとかアクセストークンとかで多分そのような権限制御するんでしょうね多分ねっていう感じかなあとアドミンって他に変えれるのないんだっけってところですかね多分パスワード以外にも

ユーザー名とかが多分アドミンに順平のようにアドミンにかかってくる気がするんでもしパスワードだけ送るんだったらパッチとかだったらよかったかもしれないですねブットは送ったリソース全部変えるでパッチは送ったとこだけ変えるリクエストになるんではい

っていうのがまあたぶんじゅんぺいのフィードバックでありがとうございますでのりさんのもたぶんどのパスワード変えればいいか分かんないエンドポイントになってますねどのパスワードってのはちなみにどのユーザーのパスワード変えればいいか分からないそれってエンドポイントで指定するんですかえっと

いろいろやり方があると思うんですけど今のりさんの言ってるのだとスラパスワードだけなんででボディにはパスワードしか入ってないんでどのユーザーの何のパスワードを変えればいいか分かんなくなってるかもしれないっていうちょっとそれで言うとクッキーでそもそも認証情報的なのが送られてる前提でしたなるほどバックエンド側でどのユーザーなのかを特定した上でリセットしてるのかなっていうクッキー

クッキーでクッキーでそこまでやってたりするんですねえやんないかななんかあんまり逆にあんまり指定しないかもっていうそうなんですねこの辺どうなんだろうなんか僕がこういう感じかなと思って考えてたのがユーザーズのユーザーIDでユーザーIDの下にパスワードっていうパスでそれにプッと投げてでボディには

古いやつと違うわ今のやつと新しいやつでパスワード2個入力して確認するやつこれは悩みどころなんですけどフロントでチェックしてるからもうバックエンドはいいかなぐらいの気持ち実際どうなってんすかねちょっとそこ分かんないですけどどういう作りにするんすかねまあどうだろうな最近だとそもそも確認用とか入れないで普通に1個だけ送る

それも増えてるんですかあるんじゃないかなあるのはあるでしょうねそこまで厳密にやらなくていいよねみたいなどうせ忘れたらパスワードリセットすればいいしっていうまあそうですねっていう感じでユーザーの下のリソースだからユーザーの下って気持ちでしたけどないことはないのかってないこともあるんですねかなあなんかあんまID指定すると

じゃあ他のID指定された時のこととか考えなきゃいけないからめんどくさいかもなって思ってましたそうなんですねそれこそさっきクッキーに入ってるトークンなのかとかでたぶんいちいちチェックするのかなぐらいの気持ちでしたけどそうかクッキーまあでも確かにそうですねクッキーからログイン情報を調べてそこでリセットするかもなんかログインも同じ原理な気がするなるほどうーん

ログインは違うわログアウトとかないから確かにそう考えるとログアウトもログアウトはユーザーID入れないから入れなくてもやれるはずだからもっと言うと別にユーザー知らない面でも一致するトークン廃棄すればいいだけだからログアウトはクッキーというかトークンから誰っていうのをいちいち見なくてもよかったりしますけど

なるほどっていう感じでそういう二通り考え方があるんだなっていうところが感じれればと思いますし確かにクッキーからユーザーID取った方が実装シンプルになるかもなとは思いましたパスもシンプルになりましたねありがとうございますじゃあ次この辺からちょっとよく分かんないやつです再配達

再配達再配達オーダーのキャンセル再配達オーダーのキャンセルヤマトとか思い浮かべてもらって再発して受け付けられるじゃないですかそれをキャンセルするAPIあなたならどうしますかこれはちょっと書く必要があるかもしれないデータ構造を思い浮かべる必要がありますよねこういうAPIエンドポイントのパスを思い浮かべるときにねはい

じゅんぺいくん整いましたメソッドはいパッチはいパススラーポストハテナアイテムイコール何番でボディボディポストステータスみたいのをキャンセルで送るステータスキャンセルはいおはようございますはいのりさんお話ししますはい僕はですねポストはい

本当は追跡番号を英語にしたかったんですけど語彙力がなくわからなかったのでオーダースラーオーダーIDがパスパラメータになっていてさらにスラーキャンセルおそらくこの注文をキャンセルできるってことは誰でもできちゃいけないのでトークンがおそらくメールかなんかで付与されてるはずだと思うので

トークンをボディで送りたいん?待てよメールからトークンボディで送らないと可能なのか無理だなゲットになるな追いついてないですえっとはい注文あ待てよいやゲットで送るわゲットで設計上の制約の問題でゲットで送りますはいはいでオーダーズすらオーダーIDすらキャンセルがパスはいでクエリストリングでトークンを送るはい

トークンはメールおよびLINEのような連絡してくるツールのURLにしか埋め込まれていないなるほどねになるかもはいありがとうございますこれは別に答えないんですけど僕はデリートでユーザーズIDオーダーIDリデリバリーのさらにリデリバリーの下にもID

っていう風な形にするかなって思っててこの気持ちは再配達もキャンセルした後にその再配達がキャンセルされてもう一回再配達したよみたいな履歴を後で追う必要があるんじゃないかと思ってこんな細かいことやってるんですけどあとはリソースも別に論理削除だと思うんで論理削除デリートだけど論理削除っていう感じでやったんですがのりさん言ってる通り

トークンつけなきゃいけないですね確かにねでもデリートでやるのかな専用のアプリとかがあるならLINEとかでやる場合どうなんですかねLINEの場合だと多分メッセージからAタグみたいなリンクでしか遷移できないからLINEのアプリってやったことあります?サイヤルタッチとかあるあれって多分LINEのアプリからそのまま何かのAPI叩いてるんですよねきっとそっかそうなのかはい

やりたいこと何でもできそうですよねそれならゲットじゃない方がいいとは思うLINEのIDかなんか送ってるのかないやでもあれって結局リンクだったような気がするんだけどリッチメニューみたいなやつですよねそうそうそうそうちょっとごめんそこは分かんないわちなみにじゅんぺいがパッチにしたのはポストを改善したいから改善じゃない更新したいからってことですよね

はいステータス1だからこれだと1ポストのその配達単品がどうなってるかっていうステータス感しかできないっていう制約が生まれるんですね何回再配達したとかが後で追えない実は裏側でそれ専用のテーブルかなんかがあって追ってるのかもしれないですけどログかわかんないけどそういう制約が生まれ得るかもしれないぐらいのフィードバックしかできないですねなんか正解がないんで

ちなみに今その履歴の話に行ったんでちょっと弁明させてもらうとですね最初ポストで言ったんですけど

どっちかっていうとこれって履歴を追加していくイメージなのかなっていう裏側でなのでポストにしてたっていう背景がありますねじゃあ今どうなってるかはその履歴一覧の中の最新のやつを見て最終的にそのなんかこの配達をどう追跡するかみたいなところは履歴のやつ全部丸と取ってきてやればいいじゃんっていうその履歴一個がめちゃめちゃ長くなることは多分ないと思われるのでまあ都度そこを

改変するのかそれともノンSQLとかで1個丸ごと履歴のJSONとして保存しちゃうのか方法はさておき基本は追加していく方が履歴たどりやすいのかなっていうのは思ってましたね履歴見る最終的には履歴参照されることが多いでしょうからとはいえそんなないと思うんですけどあれのってどうなってんだろうな文言DBみたいなので

ヒストリーみたいなオーダードキュメント違うなオーダーコレクションRDSでいうとテーブルの中に1オーダーが管理されててその1オーダーの中のヒストリーズみたいな配列に1個ずつ操作が入っていくんですかねどうやるんだろうねいろんなやり方あるだろうけどRDSなら多分

RDS?間違えたRDBなら履歴用のテーブルありそうじゃないですかはいノーSQLなら確かにJSONで一個ずつ追加していきそうオーダーをキーにしてノーSQLって言ってもあれねドキュメントとキーバリュー両方いけると思うキーバリューがいいのかな早そうだしシンプルだしなるほどすみませんちょっと消化不良かもしれないですが問いかけでしたラストLINEの

既読API既読つける伝わりますかLINE開くっすよね遠くね新着メッセージきましたパーって開きました既読が向こうに伝わりますその時多分何かのAPIが叩かれてるはずそれこれはむずいぞこれよだれじゅるじゅる問題かもしれないこれむずいぞこれどう作りますかこれはLINEの人正解知ってると思うんですけどね

こいつらバカやってって思われるかもしれませんがまあちょっと事前に機能のイメージの擦り合わせなんですけどあれトーク開くトーク開いたら未読メッセージ全部に既読がボーンってつきますよね多分そういう機能です既読はメッセージごとにつくのかなこれめっちゃむずいなむずいぞめっちゃむずいっすか

一個質問いいですかグループラインとかも関係あります?あると思ってますよですよねだから1対1でもグループラインでも使いますか分けるか任せます設計者側に任せます遠く開かなくても遠くのリスト画面で横にシュッてやると全部記録にするみたいなやつもありますね同じAPI叩いてるんでしょうね

楽しそうだねできましたはいじゃあ回答を聞きますメソッドポストはいスラユーザースラルームクエリルームIDイコール何番スラメッセージごめんなさい迷子になりましたえっと

スラユーザースラルームでクエリって言った?ハテナハテナルームIDイコールIDのスラルームIDイコールルームIDで番号送るスラメッセージハテナアンリードアンリードメッセージクエリの後ハテナスラいけないんでしたっけ

いけないと思ういけないなアンドにしますルームはてなルームIDイコール何番はてなかつかつかつメッセージ普通にアンドでつなぐねアンリードメッセージいやもうこれ一つしか選べないじゃないですかもう

なんてこと?どうしたどうした?でもしょうがないしょうがないアンリードメッセージイコールナンバーみたいなやつをパスにしますボディはリードっていうキーでダウンを送りますはいはいはいポストですらユーザーすらルームここからクエリでルームIDと

アンリードメッセージを指定するとでボディにはリードイコールダウンはいありがとうございますノリさんお願いしますはいポストでスラルームスラルームIDスラリード発音はレッドでボディでメッセージIDリストはいはいはいでアプリ上の中にある未読のメッセージ

の配列をIDの配列を送りますはいはいはい認証情報は先ほどと同様クッキー的なものでやりますはいはいはいはいありがとうございますここから何の話をしていこうかなって感じなんですけどはい一旦僕こう思った話をしますねはいもうなんかみんな違ってみんな良いレベルだと思うんで僕パッチにしてスラトークトークIDトークIDの中のスラ

メッセージ図すらレッドオールどのトークのメッセージ全部読むっていうパッチリクエストにしてボディは送らんっていうものをイメージしてました別にこれは正解ではなく俺はこう思ったってだけです確かにそれでもいけるフィードバックをしますとまずじゅんぺいくんのやつですね

多分間違いなくやばいっていうのはさっきじゅんぺいが回答してるときに言ってたこれだとメッセージ1個しか記録できないじゃん問題ですねあとはあれですかねユーザーすらルームだとユーザーに紐づくルームになってるんで多分その人だけじゃないのかそうだねルームの中にメッセージが紐づいていてさらにルームの中に別軸でユーザーが紐づいていてそのメッセージとユーザーの間に多分中間テーブルがありそうですよねうん

記録したかどうかのルーマユーザーの所有物ではないので多分これだとすごいことになりそうですできんのかなっていうかやろうと思ったら無理やりできないことはないんでしょうけどアンリードメッセージも入れたらなんかおかしいですよね多分そのクエリでルーマIDとアンリードメッセージをと思いました言った後にまあねまあね

そうかなあと多分本当だったらのりさんがやってる通りもう既読するってめっちゃ叩かれるんで結局このURL叩けば既読ですねだからボディに既読したよっていうのを多分含める必要はなかったりする気がしますねじゅんぺんはread="done"っていうのを入れてましたけどのりさんは入れてなかったですねエンドポイントでreadにしたんでredかそうですね多分これはエンドポイントでreadにするのが適切な気がする

読み込み専用のエンドポイントを作るっていうんですかねあとはのりさんのもわかるちなみにメッセージ図で読み込むメッセージを送るようにしたのって何か意図あります?あるっちゃあるですけど多分ルームID単位で記録にする機能だと将来

めっちゃヤグリなんですけど将来部分的にしか既読にしないみたいなスラックってそういうことできるじゃないですかっていうのが発生したときに結構大回収必要そうだなと思いそれなら未読のID取るだけならアプリ内でフロントでさーっていけそうだからIDをまとめて送った方が精神的に安心なコードになるのかなって思いましたわかりますわかります僕も

エンドポイントレッドオールにしたのは将来部分的に記録する機能生まれるかもなのだからあえてオールつけてるって言うんですかねエンドポイント分けで対応しようみたいなそれもありだなっていうのでいろいろやり方はあるんですけど多分今の問題のポイントはURLパスで多分記録分ける記録だけのパスを作る

っていうところかなあとはユーザーとかトークルームのリソースの関係性を加味した設計ができるかこれのむずいところはメッセージとユーザーのところですよね同じルームでもこの人は既読だしこの人は既読じゃないしとかがあったりとかその辺が結構考えるときにむずくなるポイントかなっていう気がしましたね

すごいですよねめっちゃメッセージあるから多分RDSとかじゃなくてノンエスキルでやってるじゃないですかしかも多分非読処理とかだと思うんですよすごい並列でやったりとかすると思うんでなのになんか既読数が実際にいるトークの人数超えてるの見たことないんで何かの間違いで超えちゃったりしそうじゃないですか確かに多分中もそういうのが起きないように上手いことやってるんでしょうね大会した後ももしかしてしっかり減ってんのかな

あまりそこの辺チェックしたことなかったですけど人が減りゆくLINEグループを見たことがあまりないのかもしれないまあそうかもしれないまあで

もしそれで大会した瞬間減ってるならちょっと安心します意味わかるこれで変なかったら過ごそうどうなってんだろうって思うというのにちょっと今日いっぱい問題出しました収録時間すごくことになってるんで半分くらいカットすると思うんですけど後半の問題は正解にできなかったところ正解は提示できないんですけどちょっといろいろなことを考えなきゃいけないんだなっていうのを

神できる神っていうかちょっと考えるきっかけになったらなと思ったりもしますしあと最後僕がパッチでボディなしとかって言ったんですけどこれってめっちゃレストAPIの原則反してるじゃないですか本当だったら更新するリソースを送るのがベストプラクティスだったりするんですけどこれを反してるポストとかプットとかもあるんですよ確かに存在してるんですね今回の既読みたいなのって

既読にするに決まってるんでじゃあ送んなくていいよねみたいなそういう考え方をするAPIエンドポイントの設計とかでもありだと思うんでそういう必ずしも本に書いてるものじゃないパターンもあるよっていうのを伝えられたらなと思いました確かにねはい

じゃあ締めますねお便り読みません行っちゃったんで時間がねAPIエンドポイント選手権やったんでもし問題とかありましたらねXでハッシュタグひまじんプログラマーで出題いただけますと我々がリプライで回答しますのでできるかな無理かAPIエンドポイント大喜利っていう新ジャンルできたりしませんかね無理か大喜利なのかな

悩みがあったらちょっとこれパズル感あって楽しくないですかこれねすっごく頭の体操になりますね頑張りますパズル感あって楽しいんであとはなんか僕だったらこうするとかあったらねよりそれっぽいの出されるとグサッとくるんでお願いしますプロポーザルお待ちしてます

あとはポッドキャストの説明欄からGoogleフォームで番組のお便りをご質問・感想を何でもお待ちしていますのでお気軽にお願いいたしますお気軽にどうぞ着実に読んでいきますので時間かかって申し訳ないですがお願いしますまた各種ポッドキャストプラットフォームでのフォロー・高評価もお待ちしていますのでお願いいたしますお願いしますまた何かのクイズでまたクイズ出せるように頑張って仕入れていくのでその時お願いします

また来週あのこのクイズ怖いじゃないですかやんのはい怖いそうクイズ答えないの怖いんですよクイズ答えないコツはクイズ作ってくることなんでいやいや作ってきても結局解説の時間がありますからねいやまあでもねアドリブじゃないんで確かに解説アドリブじゃないんですよ調べれるのね多少ねまああのLINEの既読とかに関しては調べられないんでマジで本能の思うくまなんですけどうんうんうん

序盤のやつとか調べてるんではいじゃあまた次回バイバイ