未経験からweb系プログラマーになるための独学履歴~触りだけでもWeb APIを理解してみよう編~

##このコーナーについて

私は根っからの文系なのでプログラミングや情報技術についてはITパスポート程度の知識しかなく、現在は全くの独学でコードや言語等のスキルの勉強はチュートリアル等でコードを書いて成果物を作りながら学んでいけるが、それらの過程で出てくる用語や技術についてはイマイチ学びきれない。
なので、折に触れて書籍及びQlita記事等のネットサーフィンで学んだ座学的知識をアウトプットすることがこのコーナーの目的である。


##Web APIについて

大まかに言えば、HTTPプロトコル間に存在するインターフェース（GETやPOSTなどのHTTPメソッドやJSONやXMLなどのパラメータ、URI、レスポンスの形式）のことをAPIといい、それらを外部から呼び出す仕様、もしくはそれらを呼び出す側のシステムに対しての呼び出される側のシステムのことを指す。

そしてAPIについてアクセスするための関数がcURL関数である。
簡単な例を出すと例えばGoogleのトップページからcURLで情報を取り出してみるとすると以下のようになる。

```php:簡単なcURLの使い方

<?php

$url = "https://www.google.com/";

// cURLセッションを初期化
$ch = curl_init();

// オプションを設定
curl_setopt($ch, CURLOPT_URL, $url); // 取得するURLを指定
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); // 実行結果を文字列で返す
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); // サーバー証明書の検証を行わない

// URLの情報を取得
$response = curl_exec($ch);
curl_close($ch);

// 取得結果を表示

echo "<pre>";
echo $response;


?>

```

実行するとHTMLのみで構成されたGoogleのトップページが表示される。

ちなみに文字列でデータを見たい場合は
以下のコードに差し替えるか、ソースコードを見ればいい。

```PHP:htmlspecialchars
// 取得結果を表示
echo htmlspecialchars($response);
```

今度は実際にWeb APIから情報を取得してみる。
今回はQlitaに用意されているAPIを使って、Qlitaで自分が投稿した記事の一覧を作成日時の降順で返し、そのHTML情報を取得する。
コードは以下のようになる。

```php:WebAPIからcURLを使って情報を取得してみる。

<?php

$url = 'https://qiita.com/api/v2/users/shitikakei/items?page=1&per_page=5';

// cURLセッションを初期化
$ch = curl_init();

// オプションを設定
curl_setopt($ch, CURLOPT_URL, $url); // 取得するURLを指定
curl_setopt($ch, CURLOPT_FOLLOWLOCATION,1);// HTTPヘッダの一部を返す
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); // 実行結果を文字列で返す
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); // サーバー証明書の検証を行わない


// URLの情報を取得
$response = curl_exec($ch);
$result = json_decode($response);

// 取得結果を表示

echo "<pre>";
print var_dump($result);

curl_close($ch);

?>

```

すると各プロパティがHTML形式で表示される。

以上を見ればWeb APIがどういうものなのか簡単には理解できただろう。
この技術は、私達の生活の中でもはや欠かせないものとなっていて例えばAmazonのアフェリエイトなんかはAmazonから商品情報を取得して、自分のサイトやブログに表示することで訪問者をAmazonに誘導し、誘導した先で訪問者がその商品を買えば収益の一部を得ることができる。
また、TwitterはAPIを公開しているのでそれを取得することでTwilogやユーザーのツイートを分析して様々な結果を出す診断アプリ、bot、サードパーティによるTwitterクライアントの作成など様々な周辺サービスが展開されている。
情報が簡単に抜き出せ、かつそれが二次・三次と利用できるようになっていると書くとこのご時世不用心なのではと思わなくもないが、利用規約は著作権の概念はきちんと存在するということと、何より

>>Amazon、Twitterともに、自分たちのデータをAPI経由で無料で提供しているので損しているようにも見えるが、新しいシステム、サービスを公開する力を持った開発者にAPIを公開することで、彼らがサービスに付加価値を与えてくれて、コアとなる自分たちのサービスがより発展する力をもらうことが出来た。(https://qiita.com/NagaokaKenichi/items/df4c8455ab527aeacf02 より)

こういうメリットが大きいということである。
あえて言及するのも蛇足だが、Amazonアフィリエイトの利用者それぞれが広告になり、小売店のような存在になっているという点が1番わかりやすいのではないだろうか。

その他、Web APIに関しては簡潔かつわかりやすくまとまっている記事があるので一読してほしい。

[Web APIとは何なのか](https://qiita.com/NagaokaKenichi/items/df4c8455ab527aeacf02)


・RESTという技術について

Web APIについて簡単に取り上げたところで、その形式として主流となっているRESTという技術について『Webを支える技術』（以下書籍）よりいくつか引用しておく。

>>（前略）Amazonは、自社が扱う書籍やそのほかの商品の情報をWebを通してプログラムから取得できるようにしました。その際に、Amazonは、SOAPを用いた形式と、ある定められたURIをHTTPでGETする形式の2つを用意しました。技術的には正確ではないのですが、後者は便宜的に「REST形式」と呼ばれました。(書籍 p.22）

SOAPというのは先に紹介したQlita記事でも取り上げられているが、RESTの前に主流だったWeb APIである。
書籍中でも大きく取り上げられているが、かなり深度がある情報になっているので、私のような初学者等はまず最低限として

[今さら聞けないWebAPIの実装方式RESTとSOAPの違い](https://qiita.com/pink/items/f1a22840619d3b79c4f2)

この記事及び、書籍より引用させていただいた部分を頭に入れておきたい。

>>REST API
RESTはREpresentational State Transferの略。
RESTの世界では、ネットワーク上のコンテンツ(リソース)を一意なURLで表すのが基本。
各リソース（URL）に対してGET,POST,PUT,DELETEでリクエストを送信しレスポンスをXMLやjsonなどで受け取る形式（レスポンスのフォーマット形式は指定されていない）。
RESTはURLがリソースに対応づけられるためURLは名詞的になることが多い。

SOAP API
SOAPはSimpleObject Access Protocolの略。
リクエストおよびレスポンスともにXMLフォーマットのデータで行う形式。
SOAPのURLは操作と対応づけられるため、URLの命名が動詞的になることが多い。

>>RESTでは不特定多数を対象にした、入力パラメータが少ない情報配信や検索サービス等での利用に向いている。

SOAPでは複雑な入力を必要としたり、入出力に対してチェックを必要とするようなサービス等での利用に向いている。

>>RESTを否定する人々の主張は、「Amazonのようにセキュリティが必要のない簡単なWeb APIでは、URIをGETはするだけのシンプルな方式のほうが利用される。しかし、基幹システムなどでトランザクションや信頼性が必要なときは、RESTでは機能が不十分である」といったものでした
(書籍 p.23）

それぞれの引用を見ていただければわかるが、かなり省いて言うとその違いはリソース(URL、URI)とGET,POST,PUT,DELETEというHTTPプロトコルの基本さえわかっていれば扱えるというREST形式の簡単さ利便性に対して、良くも悪くも規格というものに重きがおかれるSOAP形式というべきだろうか。

また、下記のページにて回答者が以下のように回答しているような違いもある。

SOAP とRESTの違いについてわかりやすく教えていただけませんでしょうか？](https://teratail.com/questions/34703)

>>SOAPはかっちり決まった規格であり、RESTは思想とか設計指針であるという、段階の違いです。 
SOAPは規格としてかっちり決まっているだけに、公開されているSOAPサービスをもとにアクセス用のクライアントクラスやサーバークラスを自動生成できたりします。 
RESTは思想・指針ですからそれにどのくらい従うかは開発者次第であり、だから形容詞として「RESTful（REST的である）」なんて表現をしたりします。

ここまで書けば私でもなんとなくその違いを理解できたが間違えてはいけないのはSOAPがRESTに対して一概に劣っているとは言えない点である。
ではなぜ先述したとおり、メリットがあるとはいえ一見するとセキュリティや信頼性など問題があるように見えるRESTが主流であるのかという疑問の答えの一つとして、書籍の引用を挙げておく。

>>（前略）Web2.0で重要だったのはマッシュアップ（Mashuup)です。マッシュアップとはいろいろなWeb APIが提供する情報を組み合わせて1つのアプリケーションを実現する手法のことです。マッシュアップでは手軽さが求められたため、Web APIが提供するリソースをHTTPやURIで簡単に操作できるRESTスタイルのほうが受け入れられたのでした。（書籍 p.23)

##参考
[Web APIとは何なのか](https://qiita.com/NagaokaKenichi/items/df4c8455ab527aeacf02)

[今さら聞けないWebAPIの実装方式RESTとSOAPの違い](https://qiita.com/pink/items/f1a22840619d3b79c4f2)

SOAP とRESTの違いについてわかりやすく教えていただけませんでしょうか？](https://teratail.com/questions/34703)

『Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus 』　山本 陽平 (著)