新年明けましておめでとうございます。今回も昨年の特集に引き続き,2016年を振り返りながら2017年のAPIに関わる技術動向などを予想していきます。Service)など,サービスの実行環境は少なからずインフラによる運用を意識した構成にすることがほとんどでした。Service(PaaS)のようなフルマネージドサービスを使ったサーバーレスアーキテクチャが,現実のプロダクトやサービスに適用できるほどまで洗練されたサービスとなってきました。このパラダイムシフトは,これまでのウェブアプリケーションの開発・運用スタイルを大きく変える可能性があります。Microservicesの文脈で語られていたことです。サービスを小さく保ち,開発を容易にし,デプロイを気軽に行いやすくなっただけでなく,サービス運用におけるインフラ障害への対応責任をクラウドサービスに任せしてしまうことで,サービス開発チームの中に専門のインフラエンジニアを割り当てなくとも開発・運用が行えるような環境となってきました。これは本当に大きなインパクトを持ちます。チームが小さくなろうとも,インフラというステークホルダは,ビジネスサイドとの折衝からはどうしても遠い立場です。そのインフラとの情報共有が不要となり,よりビジネス開発に割く時間が増えるという未来が近づいていると思います。今後はクラウドサービスをいかに上手く組み合わせて要求を満たし,かつスケールさせていくかにフォーカスが移ろうとしています。そのような中でオンプレミス環境におけるMySQLなどのデータストアをクラウドストレージ環境に円滑に移行させるようなソリューションなどが登場してきて,移行がより進むのではないかなと予想しています。これが多様なビジネスロジックにおけるエラーを表現するにはあまりに語彙不足であるのは周知の事実でした。そのため,各サービスで独自のエラー表現が量産されることとなり,同じ手法でエラー表現を記述し,それを利用するといった環境ができていませんでした。APIsというエラー表現をJSON/XMLで記述するための仕様が2016年5月に登場しました。Codeの異なるエラー表現を可能にしました。今後はこのフォーマットが広く使われていくことが期待されます。Schemaは公式サイトで説明されているとおり,JSON文書に注釈をつけて検証を行うためのSchema言語です。現在普及しているのはv4と呼ばれるバージョンですが,2016年10月にv5仕様の候補がIETFのdraftとなりました。Schema仕様は次の3つから構成されます。SchemaCore仕様ではv5仕様全体の概観を提供しつつ,プリミティブ型の定義やインスタンスの等価性の定義,スキーマの拡張方法など全体として共通の定義が行われています。全体としての変更は小さいように見えますが実はかなり影響の大きい変更が提案されています。詳しくは紹介しませんが,次の2つの変更が大きいと考えています。Schemaの独自定義に変更Validation仕様では,大きな変更はありません。Relationが削除されたり非推奨になりました。methodプロパティにもgetかpostしか記述できなくなるなど,Linkに対する操作を明確に定義する方向性ではなく,あくまでRESTとして自明の操作を暗黙的に指し示すようなものに方向性がシフトしているように見受けられます。このように,Core仕様では実装に大きく影響を与えるであろう変更が提案され,APIの記述言語としては貧弱になることから,この方向性ではv5の先行きはあまり芳しくないと予想しています。これからのdraftの積み上げに期待していきたいと思います。Initiativeが2015年11月に立ち上がりました。本格的な活動は2016年から始まったようで,現行仕様である2.0をベースに次期バージョンである3.0の検討が進んでいます。Schemaがvalidationルールを記載することによるリソース定義に主眼が置かれ,APIのインターフェースを定義するには貧弱な語彙しかなかったのに比べて,SwaggerはAPIリクエスト/レスポンスに対して詳細な記述をJSON/YAML形式で記述が可能な仕様になっています。大手が参画したことからSwaggerを導入する企業が増えた実感があります。v4をそのまま利用した上で,足りない部分のインターフェースを明確に定義できる仕様になっているところです。したがって周辺ツール群も充実しています。主要なものとして以下があります。CodeGenを用いて20以上のプログラミング言語のボイラプレートサーバーを生成できます。40以上の異なる言語のSDKを生成します。UIを通じて継続的に実装であるSwagger定義に追従したAPIドキュメントも生成できます。Editorが存在します。このようにSwaggerはAPI開発をドライブさせるためのAPI記述仕様であり,また周辺ツールはよりMicroservicesの文脈の一つであるサービス単位の小さなチームによる開発を促進していくものになるでしょう。Gatewayの定義に対してSwaggerの定義をimport/exportできることから,API開発は設計を中心として実装のありとあらゆるところまで同期したスタイルになっていくと考えられます。終わりに2016年で筆者が注目したAPI界隈のトピックの表層をざっと振り返ってみましたが,2017年はどのような展開を見せるでしょうか。サーバーレスとフルマネージドサービスの流れは最早止まらず,その流れだけでも開発においてのプログラマやエンジニアの役割が問われるような年になっていくのではないでしょうか。そこに加えてSwaggerのような仕様及び周辺ツールが整ってくると,いよいよ枠組みを構築しさえしてしまえばCI/CDを,Microservices全体を貫き実現できるようになっていくと考えられます。AIの発達に伴う雇用の未来が変わると予想されているように,API界隈の技術革新でも専門分野に対する役割の変化が訪れるはずです。新春早々うかうかできない結びとなってしまいましたが,エンジニアとは学び続けなければならない宿命です。今年も頑張りましょう。Platform全般などの講演・執筆などを行っている。最近は専らホビープログラマで業務で必要なライブラリを気が向いた際に書く程度で,普段はリサーチから提案,設計全般などに取り組んでいる。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。