APIはシステム連携で使われるため、一度開発してから頻繁に手を入れなくなるかも知れません。しかし常に新しい人たちが使っていくことを考えると、レガシー化して古い技術を使い続けるのも躊躇されます。そこで今回はAPIがレガシー化しないための方法を紹介します。 常に手を加え続ける APIは一度作って終わりではありません。むしろ放置してしまうと実装がどうなっていたのかを忘れがちで、半年や一年後にメンテナンスもできなくなります。その結果、メソッドを分けたりして、全体のバランスが悪くなります。 逆説的ですが、常にメンテ

GraphQLを提供する際にイチから構築する必要はありません。すでに各種プログラミング言語向けにサーバ実装が登場しています。今回は言語、フレームワーク別にGraphQLサーバ実装を紹介します。 Go neelance/graphql-go まだ開発途中ですが、2016年10月GraphQL仕様の全実装を目指して開発が進められています。 rgraphql/magellan リアルタイムストリーミングをサポートしたGraphQLサーバです。通信にはWebSocketを使っています。 Node.js graph

単一のエンドポイントで、クライアント側で指定することで任意のデータを取得できるGraphQLですが、ビジネスで利用する際に必ず注意しなければならないのがセキュリティでしょう。GraphQLを利用、提供する上での注意点を紹介します。 認証 GraphQLではサーバサイドのデータベースのようにID/パスワードのような仕組みは用意されていません。他のAPIと同様に、認証技術と組み合わせることができます。例えばOAuth2であったり、トークン認証になります。これらは自分で実装する必要があります。 そのため、RES

RESTful APIがIT業界で普及していますが、その反面で様々な限界も見えてきています。一つのリソースをパーマネントリンクで扱う分には簡単ですが、一覧や関連データを取得する、さらに一覧の絞り込みをしたいとなった時に突然煩雑になってしまいます。 そうした中で考えられているのがREST APIに置き換わる技術です。 OData Microsoftが提唱しているプロトコルで、HTTP/HTTPSを使います。クエリを記述することでデータの取得はもちろん新規登録や更新、削除も可能です。開発ツールも充実しており、

これからAPIを公開しようと考える企業は多いはずです。APIは単に作れば良いわけではなく、周辺の情報も一緒に整備していく必要があります。それらが抜け落ちると誰も使ってみようと思わないでしょう。 今回はAPIを開発する際に最低限チェックしたい6項目を紹介します。APIを公開する際にチェックしてもらうとよりスムーズな立ち上がりが期待できるでしょう。 APIフォーマット まず当たり前ですがAPIを作成しなければなりません。最近の流行としてはURLとHTTPメソッドを組み合わせたRESTful APIが人気です。

APIを使ったシステム開発で常に問題になるのがレスポンスです。一つ一つのレスポンスは高速であったとしても、リクエスト数が増えればトータルのレスポンスが遅くなっていきます。 今回はAPIのレスポンスを最適化するためにできる改善案について紹介します。 処理の並列化 10回のリクエストを順番に行なっている場合、前の処理が終わるまで次の処理ができません。一つでもレスポンスが遅い処理があると、それがボトルネックになって全体が遅くなります。それを防ぐのが並列化です。 JavaScriptなどはネットワーク処理が並列で

RESTful APIはモデルごとにパスを作成し、IDをつけてCRUDなデータの操作を行えるようにしています。これはとても分かりやすい反面、クライアント側ではレスポンス形式を指定できないという欠点があります。 場合によって欲しいデータが異なる際には ?include=friends のようなパラメータをつけたり、別なAPIを追加したりして対応します。こうした拡張はRESTful APIに比べると打算的で、あまり良い設計になっていないことが殆どです。 そうした問題を解決できるかも知れないのがFacebook