データ活用やDXがどんどん解る用語集　　　
REST API（Representational State Transfer API）

REST API（Representational State Transfer API）とは、インターネット経由で様々な機能やデータなど離れた場所のリソースを呼び出す手段として広く利用されている、APIのアーキテクチャスタイルのことです。
シンプルさを重視した仕様となっているため実装も利用もしやすく、HTTPプロトコルなどすでに広く普及しているテクノロジーをうまく利用しているためインターネットでの利用に適しています。このようなアーキテクチャスタイルを生み出した「REST的な考え方」に従っていることを「RESTful」と呼ぶこともあります。

APIとは Application Programming Interfaceを略した言葉です。人がコンピュータを利用するインタフェースとしてマウスやキーボードが提供されているように、外部のアプリケーションから、そのアプリケーションやクラウドサービスなどの機能やデータを利用するために提供されているインタフェースのことをAPIと言います。

API自体の解説記事もあります
⇒ API｜用語集 Vol.6 

コンピュータでプログラムを動かして何かを実現しているときには、様々な「機能呼び出し」がなされています。ほとんど全てのアプリケーションは外部の機能、例えばOSの様々な機能を「OSのAPI」を呼び出して利用することで動作しています。画面の描画やマウス操作などの基本的な機能もAPI経由で実現されているものです。

自身のコンピュータにある機能を呼び出すだけでなく、別のコンピュータの機能も同じように呼び出せるならばさらに多くのことが実現できます。コンピュータネットワークの普及が進んで、実際にそのような機能が利用されるようになります。たとえば、離れたコンピュータ上のプログラムの機能を通信ネットワーク経由で呼び出す機能である「RPC（Remote Procedure Call）」などです。

さらに進んで、多数のコンピュータがネットワーク上で通信しあって協力し合えたなら、もっと高度なことが実現できます。そのためには、単に別のコンピュータの機能を呼び出せる程度ではない機能も必要になってきます。複雑なデータのやり取りや、ネットワークを介してコンピュータ同士が通信相手をうまく見つけてやり取りをスムーズに実現するための機能も整備されるようになります。その手段として、機能が揃った本格的な通信プロトコルやそれを実現するソフトウェア（ミドルウェア）も整備されるようになります。

このようにコンピュータから別のコンピュータの機能を呼び出して利用できる機能の整備が進んでいましたが、REST APIはその状況から新たに提案された考え方でした。これら旧来のプロトコルは本格的で様々な機能を備えているものの、複雑な仕様になっている傾向がり、利用についても面倒なことが多く、利用には学習が必要で、ミドルウェアを利用する必要があり、簡単なことを簡単に済ませることができない面倒なものでもありました。

クラウド時代が近づくような、インターネット上のITシステムでのビジネス活動が盛んになりはじめた時期、「簡単なことをシンプルに実現できる」新しいAPIの実現手段が求められるようになります。そこで提案されたものが、「REST的な考え方」に基づく新しいアーキテクチャスタイルによるAPI実現の考え方でした。

REST APIは、インターネットで普及している技術や通信インフラをそのまま利用し、HTTP通信、つまり人が「WebブラウザでWeb閲覧しているとき」に利用している技術と同じ考え方で、インターネット経由でのAPI呼び出しも実現する考え方で実現されています。

HTTP通信（Web閲覧）と同じプロトコル

URLを与えられたWebブラウザが、インターネットの向こう側のWebサーバからHTMLドキュメントを取得して表示するHTTPプロトコルの仕組み、それをそのままAPI実現の基盤として利用しています。つまり、人がWebブラウズを行うときの仕組みをそのまま利用しています。

HTTPプロトコルはシンプルな仕組みで理解しやすいだけでなく、Webブラウジングはその利用があまりに広く普及しており、関係することは圧倒的なくらいに整備済みです。そのような「整備済みの状況」もうまく活用することができます。

URI（URL）をそのまま使う

郵便物なら何らかのルールで住所を定め、住所に基づいて配送する仕組みを作って整備しなければ届きません。インターネットの向こうの通信相手の機能を呼び出す場合でも同じで、何らかの方法でそれぞれの相手を区別し、その相手を呼び出す手段が必要になります。この問題に対し、新たに仕組みを整備することなく、「WebブラウザのURLと同じ仕組み」をそのまま流用します。

例えば、「www.example.com」のような形で通信相手のサーバを特定します。さらにはそのコンピュータが呼び出せる機能を多数持っている場合についても、URLと同じ仕組みで区別します。例えば「www.example.com/users」というようなスタイルで、多数の機能を解りやすく個別に指定することができます。

通信インフラもそのまま使える

通常のWebアクセスと同じ仕組みですから、インターネットの通信インフラもそのまま利用できます。URLを使って相手に到達する仕組みはもちろんそのまま使え、httpsを使って安全に通信する仕組みもそのまま利用でき、キャッシュを使って大量のアクセスを処理する仕組みなどもそのまま流用できます。

通常のWeb閲覧と通信は同じですから、新しいハードウェアどころかネットワーク機器の設定変更すら行う必要がありません。つまり、APIを利用したい人たちが、自分たちで何も整備しなくても既に全世界にインフラが揃っていることになります。

呼び出すときの「動詞」もHTTPのものを流用

例えばRPCでは、呼び出したい処理の関数名にパラメータを付して呼び出しを行うスタイルが主流でした。支社のメンバ全員の情報がほしいなら「allMembers(支社名)」など、行いたいことをそれに対応した個別の「動詞」で指定して呼び出すようなスタイルです。

これに対してRESTでは、HTTPプロトコルで定義された動詞「HEAD」「GET」「POST」「PUT」「DELETE」を使います。このうち、「PUT」「DELETE」は通常のWeb閲覧ではほぼ使われていませんが、規格においては実装されているものをうまく利用しています。

この動詞の意味を読み替えて「GET（データ読み取り）」「POST（データ作成）」「PUT（データ更新）」「DELETE（データ削除）」とすれば、データベースアクセスでのCRUD（作成：Create、読み出し：Read、更新：Update、削除：Delete）とそのまま対応させることができます。例えばこのようにすれば、一般的なデータベースアクセスと同じ能力の処理がHTTPプロトコル経由で利用可能になります。

パラメータを渡す方法もHTTPのものを流用

API呼び出しでのパラメータの渡し方もHTTPプロトコルのものを用います。GETリクエストでのパラメータや、POSTリクエストでのパラメータ（やファイル）の渡し方をそのまま用います。

ステートレス

HTTPと同じくREST APIでは、API呼び出しは状態を持たずにステートレスにします。状態がないとはどういうことかというと、前後の呼び出しの文脈に依存せずに「同じリクエストをすれば同じ結果が戻ってくる」ということです。あるいはAPI呼び出しはその都度、そのリクエストに含まれるパラメータ自体で、その処理に必要な全ての情報を保持します。

これにより、API呼び出しを処理する側において、前後のリクエストの文脈を参照することなく、いま届いたそのリクエストだけを処理し応答を生成できます。実装が簡単になるだけでなく、同じリクエストで同じ結果になることで、キャッシュの活用（処理の高速化や高負荷がかかるAPIの実現が容易になる）も行いやすくなります。

処理結果を戻す方法もHTTP世界のスタイル

APIから処理を行った結果を戻す方法についてもHTTPプロトコルのやりかた方をそのまま用います。RESTが提案された論文では、データ形式についてもHTMLなどを用いる提案がなされており、HTMLを利用すれば外部リソースを参照していることもHTMLのスタイル（アンカータグなど）で伝えられるなど既存の技術を利用できるとしています。

実際にはJSONフォーマットで結果が戻されることが多くなっており（JSON/REST）。XMLが使われることや、その他にはCSVや画像ファイルが戻されることもあります。JSONはWebブラウザ上で動作するプログラミング言語であるJavaScriptのデータ（オブジェクト）の記述方式に由来しており、処理がしやすいフォーマットであるだけでなく、人にも読みやすい形式であることから広く使われるようになったものです。つまりJSONもWeb由来の広く普及した技術がそのまま利用されたものです。

どれくらいシンプルか

REST APIがどれくらいシンプルなのかというと、人によりWebブラウザからアクセスできてしまうほどです。プログラムから利用するAPIは通常、人が利用する手段では呼び出せないことが普通で、例えばAndroidのAPIと人が直接話すことはできません。しかし、REST APIではAPI呼び出しの実行も人がWebブラウザを操作して行えてしまうことが多く、戻ってきた結果についても人でも読み取れてしまうことが珍しくありません。

通常のインターネット利用では意識されませんが、特にクラウド時代になってからは急速に大量の機能がインターネット上でREST APIとして公開されている時代になっています。

クラウド時代とはREST APIの時代でもある

昨今、クラウド活用が進められつつありますが、クラウド活用とはWebブラウザ上で利用できるSaaSアプリケーションを採用して利用するようなことだけではなく、クラウド上に多数公開されているREST APIを利用することでもあります。

例えば巨大サービスであるAWSなど大手クラウドサービス、多数ある機能がどうやって提供されているのかというと、その多くはREST APIによって提供されています。つまりAWSを活用することとはREST APIを活用することなのです。他にも数多くのクラウドサービスがREST APIで様々な機能を提供しています。

自社のビジネスにとって必要なREST APIの活用

自社がインターネット上でビジネスを行う手段として、あるいは他社との協力関係を実現する手段としても、REST APIの活用はこれから重要になるでしょう。

例えばサプライチェーンの各社が自社システムの機能をREST APIとして公開すれば、各社がそれら機能を互いに利用でき、かつてない協力関係を実現できる可能性があります。つまりサプライチェーン全体など、他社とのREST APIを通じた高度な自動化やエコシステムの構築が実現できます。

また、自社ビジネスとしてREST APIを公開することもできます。自社システムの機能を有償提供することや、無償提供して社外でのAPI利用を促すことで自社エコシステムを作る取り組みもできるでしょう。あるいはAPI経由での注文受付機能を提供してビジネスを効率化することなども可能になります。

REST APIなら簡単に使えそうだから自社でもすぐ利用してみたいと思った人、あるいは逆に、APIならばプログラミングが必要なはずだから自社では無理だと思われた人もおられるかもしれません。

プログラミングが基本的には必要

最初に書いた通り、APIは人が利用するものではなくアプリケーションから利用するインタフェースです。つまりプログラミング前提の世界です。ネット上にはREST APIの広大な世界が広がっていますが、残念ながら誰でも簡単に利用できるわけではありません。

「簡単に呼び出せる」ことは「簡単に利用できる」ではない

REST APIそのものは説明した通りにとてもシンプルな仕組みなのですが、個別のAPIの実装が簡単に利用できるかどうかは別の話です。複雑な仕様になっていて、利用にあたってドキュメントを読み解く必要がある場合もあります。

自社でのAPI公開は簡単ではない

提供する側でも同じようなことがあり、うまく考えてAPIを提供しないと外部からとても利用しづらくなって使ってもらえなくなることや、将来にAPIの機能拡張を行おうとしたときに、それが困難になってしまうこともあります。

認証機能やセキュリティなどAPI公開に伴う周辺機能

自社でのAPI公開には大きな可能性がありますが、攻撃などの悪意にもさらされるインターネットに機能を公開することになります。APIアクセスを適切に制限する認証機能やセキュリティ対策などが必要になります。

REST APIの利用は難しいと思われたかもしれませんが、それてもREST API活用を可能にする手段が存在します。「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」 や「HULFT Square」などの「つなぐ」技術を利用する取り組みです。

GUI上でアイコンを配置して設定して利用できる

プログラミング言語のソースコードを書く必要がなく、GUI上でアイコンを配置して必要な設定をすることでプログラミング相当のことが実現できます。REST API呼び出しはもちろん、現場のExcelファイルからメインフレームまで、各種のREST API以外の多種多様なシステムやデータへのアクセスが可能になります。

自分で作ることも、事前に便利に作ってあるものも利用できる

REST APIを「汎用接続アダプタ」により自分自身で呼び出し、自分でしっかり作りこんで使うこともできますし、APIの仕様が難しすぎて工数がかかりすぎる場合や自分で作りたくない場合にも、既存のREST APIを事前に使いやすく呼び出せるように整備済みの「専用接続アダプタ」で簡単かつ便利に接続先のサービスを利用することもできます。

作った機能はAPIとして公開できる

「HULFT Square」ならば、GUI上で作った機能をそのままREST APIとして公開することができます。自社にとって必要な機能として作ったものをAPIとして公開して再利用したい、あるいは他社にAPIとして利用してもらいたい機能、GUI上で作ればREST APIとして公開できます。

認証機能や利用ログの取得などAPI公開に伴う周辺機能

認証機能やAPIの利用ログの機能など、API公開に必要な諸機能も「HULFT Square」では整備されています。自社で個別に開発しなくても、既に提供されている機能を利用することができます。

iPaaSなので自社での運用不要

「DataSpider」なら自社管理下でしっかりと運用できます。クラウドサービス（iPaaS）の「HULFT Square」なら、このような「つなぐ」技術そのものも自社運用不要で利用できます。自社での導入や運用の手間もなく、APIの可能性を活用することができます。

このような「つなぐ」技術によるAPIの利用、窮余の手段ないしは簡易的な利用方法に思えたかもしれません。

確かに、腕の立つエンジニアがプログラミングやクラウドサービスを駆使してAPIを活用する方がより高度な取り組みができるのも事実です。しかし、腕の立つエンジニアが同時に自社ビジネスを深く理解していることは稀です。

APIをビジネスで活用する場合、公開されているAPIが自社業務でどのように役に立ちうるのか、その判断ができるのは業務の現場の人になります。また自社でAPIを公開してビジネスを行いたい場合、それはつまりAPIを通してビジネスをするということですから、どのようなAPIとし、利用できる機能や利用できない機能の設計や、どのように課金するかなどのビジネス的な匙加減が重要ですが、そのようなセンスに優れているのも業務の現場の人になります。

つまり、業務の現場の人が「自分でAPI世界にアクセスできる」ことは、それだけでビジネス的に大きな可能性があるのです。その都度エンジニアに依頼するよりも、自分たちで直接手を下すことができればビジネススピードも向上します。あるいは腕の立つエンジニアが社内に確保した上で、「つなぐ」技術による取り組みとうまく組み合わせることがおそらくさらに良いAPI活用を実現できるはずです。

• EAI
  • -システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
• ETL
  • -昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
• iPaaS
  • -様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。
• API基盤
  • -APIを提供する際には、APIそのものだけではなく認証機能など周辺の機能の整備が必要になります。どうしてそのようなものが必要なのかについて、またAPI基盤とはどういうものかについて。

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるオンラインセミナーも開催しておりますので、ぜひ一度お試しいただけますと幸いです。

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

• SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
• データ利活用に向けて進めたいがシステム連携に課題がある
• DXの実現に向けてデータ連携基盤の検討をしたい