RESTful API データが見つからない場合の処理

　今 RESTful API をベースに iOS や Android のアプリにデータを提供するシステムを作っています。基本的になんでも json を返します。それで、HTTP メッソードを使ったり、 HTTP Response コードを使って、フロントエンドとやりとりをしています。
　HTTP メッソードの方は特に決まってるので、Read (Get), Create (Post), Update (Put または Patch), Delete (Delete)特に問題が起きてませんでした。まぁ、たまに Read を Post メッソードを使う API もありますけど。（GET には HTTP body がルールとして使わないので、複雑なオブジェクトをバックエンドに送る時、例えば、複数検索条件とか、Post も使ったりします。）
　戻り値は HTTP Response コードなので、200 OK, 201 Created, 202 Accepted とかは理解しやすいです：Get (200 OK), Post (201 Created), Put/Patch (200 OK), Delete (200 OK) 一見ですぐわかりますので、唯一考えるべきコードは 404 Not Found ですね。
　私見ですが、データが見つかってない場合、404 ではなくで、空の データ body を返すべきです。なぜなら、404 には url が存在しない場合もサーバーから返すので、意味が紛れ易いです。
　一般的に JSON を扱うライブラリでは空の配列や []、オブジェクト {} など空のデータに deserialize しますが、空の body の場合、null に deserialize します。それで、Front End が null かどうかチェックすればいいのです。
　404 が返す場合、これは HTTP Request がエラーになったと同じ意味なので、違うルートになります。だからコードには
   if (response.StatusCode == 404) {...}
みたいなコードがあっちこっち出てくるかもしれません。そうすると、全体的にエラーの扱いが難しくなります。
　データはデータなので、見つからない場合は、200 OK, null body を返したら Front end もすぐわかります。
　もう一つは Java, Objective-C, C# などは全て Strongly typed 言語なので、JSON を deserialize する場合、一般的に一つの Class を定義しますが、データの角度から見ると、処理に合わせて、たまに Dictionary<string, object> にしたほうがやりやすい場合もあります。
　例えば、JSON オブジェクトの中に、どのプロパティの値が null かをチェックする場合、Reflection を使うより、直接 Key-Value pair にしたらい、Iteration メッソードを使えば、速いし、その後の処理も楽になるはずです。
　それでは。ここまで。

なぜ RESTful API になったのか

　おととい、チームの iOS Dev といろいろディスカッションしました。彼はまだ古い API のイメージ持っておらず、なんでもサーバー側でやると考えているようです。それで、現在の API は iOS だけではなく、Android, Web などいろんなチャンネルで共通で使う物だと、RESTful API だから、リソースを操作すると考えようといろいろ話しましたが、まだまだ受け入れてなかったそうです。

　以前、3 年前ぐらいまで、iOS デバイスなど、JavaScript の性能がボットルネックだった時代では、サーバー側で計算したり、ソートするなどをやらなければならなかった。当時の Front End はそれほど遅くなかったと言っても、パフォーマンスにいろいろ真剣に取り組まないと、すぐ遅いと感じてしまいました。それで、自分たちのラブラリを作ったり、速く見せるため、ユーザーの動作を予測して、先にデータをロードするなど、工夫していました。

　今 RESTful API になってから、抽象したデータなどをリソースと考えて、HTTP Method をマップして、CRUD -> Get, Post, Put (Patch), Delete を使って、Front end から直接操作できるようなイマージにしないといけないと思います。だから、API はデータを提供するだけ、データの操作はデバイスか Web Site で処理します。

　前では URI や Controller の名前は RegisterDevice など、動詞+名詞でしたが、RESTful API になると/devices と名詞のみなりました。それで、HTTP Get で全部のデバイスを取得したり、 HTTP Post でデバイスを作ったりします。

　GET /devices?pageNo=0&pageSize=20  -> 全部のデバイスの配列を取得

　GET /devices/{deviceId} -> 一つのデバイスを取得

　POST /devices -> デバイスを作る。データは HTTP Request Body から

　PATCH /devices/{deviceId} -> デバイスを更新

　Delete /devices/{deviceId} -> デバイスを削除

　また戻りますが、Front End は一回要求するデータはそれほど多くないので、ソートも時間のかかる処理ではなくなりました。Http Request の時間はまだ考えなければなりませんが。

　結論としては、もう新しい時代ですので、表示ロジックを Front End であるべきです。

　それでは。

C# ASP.NET Web RESTful API と Front End

　最近、仕事が Back End の方にシフトしました。以前も C# ASP.NET を使ってましたが、あまり印象が良くなかった。ただ、今回 MVC4 を使ってて、なんかコンセプトなどは Ruby on Rails に似てるなと思いました。でもやはり JavaScript の方が使い易いです。
　今作ってるのは UI いわゆる View のない API のみになります。すべてのリソースを操作できる HTTP Method を使って、RESTful です。ASP.NET Web API を使うと、結構簡単にできます。しかも Autofac を使って DI も実現できるし、あまり他の言語のフレームワークと変わらないなと思いました。
　そうすると Front End はもう最初からデータをロードするではなくて、スタティックのリソースだけロードすることになります。ページが早くロードできる利点もあるし、そのあと API を呼び出す事で、どのように表示するかも簡単に変更できます。
　さらに、Task<IHttpActionResult> の戻り値のようにマルチスレッドのコントローラーもサポートしているので、Node.js みたいに他のリソースを要求して、処理が終わったら、HttpResponseMessage などを返すようないわゆる Event Driven のスタイルもできます。このスレッドは ApplicationPool ではなく、他の pool を使うので、いつでも Request が受け付けるようになります。
　あと、NSubstitute を使ったり、Moq を使うことで、Unit Test も簡単にかけるから、全体的にいい感じです。
　
　今回もプロジェクト全体が Mobile First を利用するので、まず iOS と Android Smartphone を対象に、リリースする予定です。今までは、ほとんど Hybrid の App を作ってきたので、今回もそれになりそうですね。
　
　それでは。

RESTful API のデザイン

　先日から、新しいプロジェクトが始まりました。いろいろデザインとか、ポソナーとか紹介されて、面白そうです。今回は旧システムの改造も、 UI の改善も、モバイルファーストでする予定です。
　バックエンドは完全に書き換えるではなくて、API を追加して、フロントエンドをサポートする形になります。だいぶのロジックはフロントエンドでやる予定です。それで、フロントエンドもっと自由にデータを操作できるのように、データも RESTful API に合うように、少し改造する予定です。
　RESTful API はリソースの C(reate)R(ead)U(pdate)D(elete) を Post, Get, Put, Delete HTTP Request にマップする技術で、今は結構使われています。MongoDB なども RESTful API を提供するモジュールもあったり、CouchDB は完全に内部サポートしています。Oracle の最近の Non-SQL DB もサポートしています。
　実際作るとき、例えば、ツイターのフォロー関係も一つのリソースと考えていいです。メンバーが 登録される後、他の人をフォローすると、このような関係を DB に入れる時、実体はないけどれ、 実存しています。
　今は AJAX を使って、HTTP の Method を指定することで、Delete など直接サーバーに送ることができます。もし、JavaScript が使えない場合、現在のフレームワークは Hidden フィールドを使って、そのままサーバーで、API にマップすることもできます。

　来週から、もう完全に API チームに配属されますので、しばらくは JavaScript 触れないが、最近出てくる新しいものがあまりないし、AngularJS 2.0 も開発中ですので、ちょっと待ちましょう。：）

それでは。