第4回RESTful勉強会を開催してみました(前編)

2015年2月18日水曜日 ぷぽ

こんにちは。フルなんちゃら総務のぷぽです(・ω・)ノ
RESTful#とは勉強会4をまたまた社内で開催いたしましたので、そのレポートです。



まず最初にお詫びを!現在、外壁工事中で初めての方はだいぶ戸惑ったかと思います。そして、ゲストwifiの調子が悪く、ほとんど接続出来なくてご迷惑をおかけしました。。。私も接続できなかったです(´・ω・`)カイゼン要望を出しておこうと思います。


そんなこんなで始まった勉強会ですが、今回は「Webを支える技術」という本の読書会に全ての時間を費やしました!進め方はいつも通り。今回はグループで7章を輪読しながら、疑問点や自分の考えを述べたり、プロフェッショナルの川村さんに尋ねたりします。内容はTwitter上に投げ、最後に全体に向けて川村さんの補足タイムがありました。当日の様子は@makopi23さんがまとめてくださったtoggetterを是非ご覧下さい!


まとめをご覧頂ければ大体の内容がお分かりだと思いますが、今回は特に盛り上がった?点をピックアップし、前編後編の二部構成でお伝えしようと思います。

■POSTとPUTの使い分け

今回は事前に川村さんから読書会のポイントと、問題を提示してもらいました!
「PUTはリソースの上書きを避ける為にクライアントで事前にURIの存在をチェックしなければなりません」とありますが、どうすればチェックできるでしょうか?チェックしなくても済む方法はあるでしょうか?
私はピンと来て「GETかHEADで最初に取得してみて、なかったらPUTを送れば良い!」とドヤ顔で話していました。しかし、GETで確認した後に他の誰かがPUTしてリソースの追加が行われる可能性もあるため、「条件付きリクエスト」をすればなお良いとのことです!予習したのにそこに気付けなかった...無念。このケースでは、If-None-Match(現在のリソースがない場合のみリソースを追加する)という条件をつけてあげれば良いとのことでした。


■POST時の挙動を確認してみる

POSTはリソースの作成だ!ということで私の班では書籍通りの動作をするか確認してみる事にしました。まず、Githubの既存のissueにコメントをしてみます。しかし、POSTメソッドが使用されていないではないですか...。川村さんによると、「このコメント自体にURIが割り当てられている訳ではない(子リソースが作られた訳ではない)ので、こういう挙動じゃないのか」という事でした。しかし詳しい事は結局分からず終いです。


Chromeのデベロッパーツールで確認します

次に「issueを作るときはURLに番号降られますよね!?」という話になり、今度はissue作成時の挙動を見る事に。案の定、POSTメソッドを使用していました!しかし、よく見てみるとステータスコードが302 Foundになっています。(あれっ、201:Createdじゃない)話によるとWebアプリはリダイレクトをするためPOSTで302が返しているものが多いそうです。ユーザビリティの観点では良いかもしれないが、正しいかというと疑問があるとのことです。この辺は難しい問題ですね...。

と、そろそろ長くなってきましたので前半はこの辺で。後編もよろしくお願いいたします!