Web APIとの苦い思い出
先日、クラウド会計ソフト「freee」のAPIを使って、CLOUD PAPERと連携させることができるようになりました。今回、freeeから提供されているAPIを使いました。ひさびさにAPIを使って、昔のことを思い出したので少しお話を。
目次
そもそもAPIとは？
APIとは、アプリケーションプログラムインターフェイスの略語で、プログラミングの際に使用できる命令や規約、関数等の集合の事を指す。ソフトウェア開発の際、いちから全てを作ることは困難だが、APIを利用すればもともとあるプログラムをもとにして、自分でプログラミングすることなくその機能を利用したソフトウェアを作成することができる。
ざっくりいえば、第三者のサービスにデータを利用させるけども、直接データベースにアクセスはさせないよ。ということで制限付きで、ある程度データを取得・作成できるように考えられたインターフェイスのこと。
昔は、提供URLを叩くだけでデータが取得できていましたが、Twitterのころ？ぐらいから、OAuthというセキュアな技術が取り入れられました。よく、Twitterログインなどで、Twitterのページに飛んで認証しますか？と聞かれるアレです。第三者のサービスがログインIDやパスワードを知ること無く、固有のアクセストークンを使って、サービスにアクセスできるように考えられた技術です。
OAuthは導入が面倒なところがあったんですが、最近はOAuth2が使われ始めていて、よりかんたんに利用できるようになっていました。技術の進歩は早い。
最初に使ったAPI
APIを最初に使ったのは「ぐるなび」と「GoogleMap」でした。当時はマッシュアップという言葉が流行っていた時期で、GoogleMapでグルメ情報が検索できて、複数の住所を一括検索できるというサービスをつくりました。こんな感じで、いろいろなサービスから提供されているAPIを使って組み合わせることで、短い時間でWebサービスが作れます。
いろいろ作った中でヒットしたのは、はじめてのiPhoneアプリでした。このアプリでYoutubeとAmazonをかけあわせて、例えば好きなアーティストのアルバム順にYoutubeでアップされているPVを自動検索し、連続再生できるというものでした。このアプリは当時大ヒットし、全国ランキング3位までのぼりつめました。しかし！そんなに甘くないもので、レコード会社から著作権の関係で訴えがあり、やむなく終了となりました。
そのあと、Twitterクライアントの開発にとりかかり、Twitterに投稿するときに顔文字をかんたんに使えるアプリを作りました。これもヒットしましたが、この時はTwitter社のひんぱんなAPI変更・廃止・利用制限があいつぎ、サポートに追われ、継続することがままなくなってしまったのです。
APIを使うリスク
やはりAPIだけでサービスを作ることにはリスクがあります。提供しているサービス側も膨大なアクセスで負荷がかからないよう、利用制限をつけていたり、動作が遅かったり、APIが打ち切られるリスクなどがあり、僕自身はAPI自体でサービスを作ることをやめました。
そして、今は独自でCLOUD PAPERをスタートさせ、運用を行っています。外部に影響されず、サービスを追求できる環境が一番ですね。
[sc name=”engeneer”]
SPONSER
SHARE
YouTube
PROFILE
