API界隈における2017年の主な出来事と2018年注目のキーワード
最近の記事
皆さま、明けましておめでとうございます。2018年になりました。個人、企業ともに新しいチャレンジを行っていく計画を立てるのに良い時期です。そこで、APIという視点において今年はどんな年になるのか紹介したいと思います。
ECサイト
オンライン決済において、PCI DSSへの準拠が求められています。これは商品売買に限らず、クレジットカードを入力するような決済処理全般において対応が必要です。これは2018年03月までに対応が必要になります。
従来、購入者がWebサイト上でクレジットカード情報を入力し、サーバサイドで決済を行うのが一般的でした。しかし、昨今の情報流出やセキュリティインシデントの発生に伴ってクレジットカード情報を受け取る場合にはPCI DSSの高いレベルでの準拠が求められるようになります。これは中小規模なECサイトでは負担が大きい仕組みと言えます。
そこで最近ではクレジットカード情報をAPIで決済サービスへ送信して、一時的に使えるトークンに置き換え、そのトークンと購入額で決済を行う仕組みが提供されています。StripeやSquare、PAY.JPといったAPIで提供されている仕組みを使うことで、ユーザビリティを損なうことなくセキュアな決済が実現できます。
2018年前半まではECサイトはPCI DSSへの対応に追われるでしょう。
銀行API
2017年05月に改正銀行法が成立し、APIを提供する努力義務が銀行業界に課せられることになりました。本来、APIで安全にアクセスすべきなのですが、銀行業界は閉鎖的であったり、技術的なイノベーションが遅れることもあって、スクレイピングによるデータ取得が横行していました。これは行儀の悪い仕組みであり、Webサイトのデザイン変更によってサービスが止まってしまうといったリスクもあります。
現在、銀行では特定企業と契約を結びながらAPIを利用できるようになっています。さらにマネーフォワードではみずほ銀行、三井住友銀行、住信SBIネット銀行に対して送金が可能になっています。これもAPIを使っています（ついにメガバンクが「更新系API」を提供開始、マネーフォワードが経費精算振込で連携一番乗り | TechCrunch Japan）。
2018年においても、この傾向はさらに強まっていくと考えられます。銀行のAPIは個人情報や資産に関係してくるので一般開放は難しいかも知れませんが、企業提携などによって使えるサービスが増えていくことでしょう。
GraphQL
RESTfulの課題が幾つも散見されるようになってきました。それに対する答えの一つとしてGraphQLに注目が集まっています。RESTful APIをすべて置き換える存在ではありませんが、GraphQLを取得系APIとして公開するケースは増えています。
GitHub Universe 2017において、GitHubもGraphQLを公開しました。今後もこの流れは広がっていくと考えられます。
GraphQL | A query language for your API
Open API Specification
Swaggerを継承し、APIドキュメントフォーマットとしてOpen API Specificationが2017年07月にローンチしました。2.0と3.0には互換性がありませんが、コンバータは存在します。今後、ソフトウェアやサービスがOpen API Specificationに対応していくと考えられます。
APIドキュメントについては他にも幾つかのフォーマットが存在しますが、Open API Specificationが最もデファクトに近い存在になってきていると言えます。ツールや関連サービスなどのエコシステムが整ってきていますので、APIドキュメントをOpen API Specificationに対応させておくことで広がりを持たせられることでしょう。
OpenID Connect
OpenID ConnectはOAuth2をベースにした認証技術となっています。IDトークンとアクセストークンの発行両方に対応しています。OpenIDは認証情報を引き回すことができ、アクセストークンを使えば外部サービスのデータを許可した部分においてだけ利用できます。
現在、多くのサービスにおいてOAuth2だけでなくOpenID Connectも提供されるようになっています。提供側としては両方を、利用する側としては必要な方を選ぶといいでしょう。2018年においてもこの広がりはさらに早くなっていくと考えられます。
JSON
JSONの事実上、最後と言える仕様が2017年12月に公開されました（事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に － Publickey）。ECMAとの統一も行われ、今後はUTF-8エンコードが必須になるということが決まりました。APIにおいてほぼデファクトになってきているフォーマットだけに、仕様が固まったのはAPI利用側/提供側双方にとってメリットがあるでしょう。
JSONをイチから作るケースはそうそうないかと思います。多くの場合、各プログラミング言語についているライブラリを利用することでしょう。JSONの仕様が固まったと言える状況なので、各ライブラリも最終版と言える状態になってくるのではないでしょうか。
APIのデータフォーマットにおいてはJSONの他、XMLやProtocol Bufferなど様々にあります。しかし最も扱いやすく、人に対してもある程度可読性が確保されているフォーマットとしてJSONは今後も利用が増えていくと思われます。
APIを提供する、利用するのが当たり前になりつつある現在、2018年もAPIのエコシステムがますます広がっていくと思われます。金融系のような固い業界においてもAPIが浸透してきていますので、今年も多くの企業がAPI公開に踏み切ることでしょう。