Partsを読んでみた。Partsを読んでみた。Partsを読んでみた。書評Daisukeここ最近、サーバーサイド開発の仕事は、もっぱらAPI開発案件が増えている。APIを実装してきた。iOSやAndroidなどのスマホ・タブレットアプリのバックエンドサービスだったり、WEBアプリでも、SPA(シングル・ページ・アプリケーション)がどんどん増えてきているのが背景にあるんだろうな。(私のもとに来るサーバーサイドの話の、8割〜9割はAPI実装の話という体感。)いよいよ、サーバーサイドエンジニアのタスクから、「View」の実装が消えてなくなる時代に入るのかもしれない。APIのハウツーについて書かれた書籍は、多くの人が待ち望んでいたのかも。Parts」を買って読んでみた。どちらかと言うと、初心者向けな内容かな。APIを開発・構築した経験などが無いという方にとっては役立つ情報が結構載っていると思う。もって、API開発のハウツーを少ないページ数で上手にまとめてあると思う。私のような経験者でも、もちろん知らなかった事なども載っており、リファレンスとして役立つのではないかと思う。ページ数は200ページ程度で少なめなので、経験者の方だったら結構サラッと流し読みできる感じ。APIとはなにか(1章)「APIエコノミー」という、TwitterやFacebookなどSNSに代表されるように、APIを公開することで「ビジネスを加速」させる事ができる時代であり、公開できるDBを持ってるならAPIとして公開したほうがいいよ。いうビジネス的なお話からスタート。(本書には書かれていないけど、「オープンデータ」とかは、その流れだね。)・エンドポイントの設計とリクエスト形式(2章)エンドポイントの設計の基本が書かれている。この辺り、RailsなどのイマドキWEBフレームワークでは、普通に使われている(なんなら意識すらしない)、「RESTFul」な設計をよくご存じの方には、とても馴染み深いのでサラッと読める。(本書にはRESTという言葉は出てくるけど、RESTFulという言葉は出てこない。言葉自体はどっちでもいい。APIに限らず本書のエンドポイント・URIの設計をしっかりと学ぶべき。APIに限らず、WEBサービス・WEBアプリ開発全般で知っておかなければならない。ちなみに、経験者である私ですが。Level3は勉強し、取り入れていってみたいと思った。・レスポンスデータの設計(3章)JSONでのレスポンスデータの設計の基礎について。(XMLはもうイマドキじゃないよ、ってことで省略されている。)個人的にはほとんど私自身実践している内容だったので、ほっと胸をなでおろしていたが、一点だけ、実践できていない部分があった。JSONのデータ構造は、基本的に階層構造の表現がしやすいので、階層構造でデータ設計することが多かった。Guideによると、フラット構造の方が推奨されるらしい。Guide・HTTPの仕様を最大限利用する(4章)主に、HTTPのステータスコードとContent-Type関連について。(HTTPヘッダーね。)これ、コードの実装に集中してると、ステータスコードの設定が後回しになっちゃうことが多いので、ちゃんと正しいステータスコードを返すように気をつけよう。(私の周りのエンジニアでも、後回しになっている人多い^^;)同様に、ヘッダーのメディアタイプ(Content-Type)も後回しになりがちなので、忘れないように。(セキュリティーホールにもなるよ。APIを作る(5章)APIを公開したあとの更新(バージョンアップ)について。LSUDs系APIは、影響範囲が広いのでそのためのチェック項目。APIのセキュリティ。API開発の経験の有無を問わず、サーバーサイドエンジニアなら誰でも知っているXSSやXSRFなどについて基本的な解説。セキュリティー関係のHTTPヘッダは知らなかった。X-XSS-Protectionとか、Content-Security-Policyとか、そういうセキュリティヘッダがあったんですな〜。イマドキフレームワーク(Rails)とかだと、裏で勝手にヘッダの付与をやってくれてると思うので(確認はしていません)、気づいていない人も多いんじゃないかな。これらのヘッダも駆使したいところ。経験者の私としては、「答え合わせ」として結構よかったし、知らないこともちょこちょこあったので勉強になった。API開発の初心者の方で、「え?開発したことが無いから設計の仕方がわからない」という方はもちろん、「俺は超スマートだから大丈夫だぜ!」という方でも我流で書き始める前に、一読しておくといいと思う。(オライリー本だけど、分量は多くないので、案外サクッと読める。「それでも、京都は面白い。