解答と解説
・APIと分散コンピューティング
APIはアプリケーションの結合部の仕様を表し、最近は特にWeb（HTTP）を通して分散コンピューティングを実現するための技術を示す。中でもエンタープライズ系システムを中心に普及・発展したのがOMGの定める［Q1］やW3Cの定める［Q2］だ。
Q1
- 選択肢： CICS、VisiBroker、MQ、CORBA
- 答え： CORBA
「CORBA」はCommon Object Request Broker Architectureの略で、プログラミング言語やOSによらずネットワークを通じてソフトウェアコンポーネントの呼び出しを実現できる仕様です。VisiBrokerはCORBAに準拠した製品の名前です。他にCORBA準拠の製品としてはORBIXが有名です。CICSはIBMのメインフレームのトランザクション処理システム、MQはIBMのメッセージングミドルウェアの製品名でどちらもAPIとは関係がありません。
他に分散コンピューティングの仕様としては良くも悪くも有名なEJBがあります。EJBはJavaの仕様ですが、実はCORBAの仕様に基づいており、IIOPというプロトコルを使うことでCORBAのクライアントから呼び出すことも出来ます。
・［Q2］とSOA
［Q2］はインターフェースの定義（［Q3］）からメッセージのフォーマット（SOAP）、サービスを探し出すためのレジストリ（UDDI）まで徹底して［Q4］を活用しているのが特徴だ。HTTPのみならずSMTPやftpなど様々なプロトコルを使って呼び出しが出来ることや、「サービス」として独立させたコンポーネントを疎に結合させてシステムをくみ上げるSOAという概念も話題になった。
Q2
- 選択肢： Web Services、XML Schema、RELAX NG、ebXML
- 答え： Web Services（Webサービス）
選択肢としてXML関連の技術を並べてみましたが、簡単だったのではないでしょうか。XML SchemaはXMLのスキーマ（構造）を定義する仕様で、Web Servicesのリクエスト・レスポンスの構造を表すのにも使います。RELAX NGはXML Schemaとはまた別のスキーマ仕様で、ebXMLはXMLを使った電子商取引のための仕様です。RELAX NGやebXMLはW3CではなくUN/CEFACTとOASISという機関が策定しています。
Q3
- 選択肢： WADL、WSDL、ISBN、ISDN
- 答え： WSDL
答えはWSDL（読みは「ウィズドゥル」）です。WADL（読みは「ワドゥル」）はいわばREST API版のWSDLです。今のところ普及していませんが、REST APIのインターフェース仕様をより厳密に定義するためのインターフェース記述言語です。ISBNとISDNはどちらもAPIとは関係ない用語で、それぞれ書籍に割り振られる国際的なコードと電話回線を使ってデジタル通信を行う通信網を指します。
・［Q3］からの脱却
XML-RPCはSOAPの基盤となった［Q4］ベースのRPC技術だが、BloggerやMovableType、WordPressなど様々なブログプラットフォームが対応したことで知名度をあげた。通信プロトコルをHTTP（S）に限定しており、また仕様がシンプルで扱いやすくデベロッパの支持を得たことで広く普及した。
Q4
- 選択肢： WML、XML、WMV、RELAX NG
- 答え： XML
自明な答えですね。WMLはWireless Markup Languageで携帯電話向けのコンテンツフォーマットです。日本ではEZwebで使われていましたがXHTMLやHTMLの普及に伴いほとんど使われなくなりました。WMVはWindows Media Videoで、ビデオのフォーマットです。
・［Q5］
最近は［Q4］の冗長性が嫌われ、メッセージのフォーマットとしてよりシンプルで柔軟性の高い［Q5］フォーマットがより好んで利用される。
［Q5］フォーマットを使ったAPIとして特にデベロッパの支持を得たのがTwitter APIで、そのAPIのデザインパターンは現在多くのサービスで参考にされている。
Q5
- 選択肢： Bison、Python、JSON、Dyson
- 答え： JSON
記述が簡単ということでAPIのメッセージ交換フォーマットとして今人気なのがJSONです。他の3つはAPIとは無関係です。Bisonはパーサジェネレータとして、Pythonは言語として、Dysonは掃除機メーカーとして有名です。
・APIの認証
成りすましやサービスの妨害などを防ぐため、特に更新系のAPIでは認証や認可を必要とするものが多い。シンプルな認証の実装方法としてユーザーIDとパスワードを渡す［Q6］認証があるが、サードパーティのアプリケーションにパスワードを渡すのはセキュリティ上好ましくない。近年はアプリケーション個別に発行したキーでユーザーを識別する［Q7］が普及している。［Q7］ではユーザーのパスワードを変更することなく任意のアプリケーションの接続を遮断することが可能だ。［Q7］は現行で二つの仕様、バージョン1.0aとバージョン2.0があるがそれぞれ互換性はない。
Q6
- 選択肢： Basic、Advanced、SSL、クライアント証明書
- 答え： Basic
ユーザID、パスワードを渡す「基本的」（Basic）な認証方式としてBasicがあります。Basic認証を使う際、ID、パスワードはBase64という方式でエンコードして送りますが、可逆変換なので通信内容を傍受された場合は簡単に元のID、パスワードを割り出すことが可能です。SSLはSecure Socket Layerの略で通信内容を暗号化する仕組みです。クライアント証明書はSSLで通信をする際、サーバ側だけでなくクライアント側の身分を明らかにするための仕組みで、法人向けのオンラインバンキングやe-Taxなどでも使われています。
Q7
- 選択肢： SSL、OAuth、Authorization、Authentication
- 答え： OAuth
APIの認証方式として現在主流となりつつあるのがOAuthです。OAuthは厳密にはAPI呼び出し元の身分を明らかにする「認証」（Authentication）ではなく、アプリケーションごとに与えられた許可、認可（Authorization）を示す方式です。"Auth"という4文字からは"Authentication"を思い浮かべてしまいがちですが、認可（Authorization）とは違うものですのでセキュリティについて触れる場面では厳密に区別しましょう。
OAuth 1.0は通信を傍受されたとしても成りすましができないよう、幾分複雑な呼び出し手順が必要な仕組みです。OAuth 2.0ではOAuth 1.0の複雑さの反省から、通信をSSLで暗号化することを前提にして簡単に使えるようにしました。
まとめ
いかがでしたでしょうか？ 知識チェックですので知らなければ解きようがない問題ばかりですが、「とりあえず知っておいて損はしない」トピックを出来るだけ織り込んでみました。今回取り上げた「歴史的側面」も踏まえて理解することでその設計思想や今後のトレンドが見えてくるでしょう。
私はTwitter APIを触りはじめて7年ほどになりますが、まだまだその応用範囲の広さに驚かされる毎日です。そしてAPIの組み合わせによりソフトウェア、Webの可能性は無限大に広がります。皆さんも是非APIを使ってわくわくするアプリケーション、サービスを作って見てください！
