こんにちは、エンジニアの @return520 です。 これは 2018年モバイルファクトリーアドベントカレンダー 12日目の記事です。前日は @toricor_で「headless Chromeでお手軽にWebページのE2Eテスト」でした。 はじめに 本記事では、Twitter のツイート検索APIのPremium Search APIを、Perlで利用する方法を紹介します。 Twitterは、ツイートの検索APIを複数提供しており、Premium Search APIでは、30日前まで遡れる 30-d

Google API とは、 Google が提供するのサービスやプラットフォームを扱える API です。 これらの API を使いこなすことで、 Google のサービスを自身のアプリケーションへ組み込み、様々なことを実現できます。 ここでは、 Gmail を扱う API と、GoogleDriveを扱う API を PHP アプリケーションから利用する例に紹介します。 （内容は2018年7月現在の情報です。） この記事の内容 今回は、 Google API のガイドに記載されているQuickstart

本記事は古い記事となっております。記事執筆当時と比べてサービスそのものの仕様は変更されており、本内容については無保証とさせていただきますので、本記事をご参考いただくのは自己責任でお願いいたします（本記事の内容については、お問い合わせいただいても対応しかねます）。またセキュリティやApps本来の機能の都合で、予告なく挙動が変更になるかもしれないのでご了承ください。 BASEと連携し、皆様が運営されているWebサービスに商品を販売する機能を追加したい！であるとか、Webサービスのユーザーに簡単に商品を販売する

こんにちは。スタメンエンジニアの松川です。 今回は、前回、市川の方からスタメンの開発コンセプトにあげられた ・ツールやライブラリをちゃんと使いこなす に着目したいと思います。 前回、紹介があった通り、スタメンではアプリケーションフレームワークとして、Ruby on Railsをメインに使用しています。 スタメンでは、「少ない人数で いかに(ラクをして)サービスの開発に注力するか」という観点の元、ライブラリとして複数のgemを活用して開発を行なっています。 gem gemとは、サードパーティ製のライブラリの

APIはシステム連携で使われるため、一度開発してから頻繁に手を入れなくなるかも知れません。しかし常に新しい人たちが使っていくことを考えると、レガシー化して古い技術を使い続けるのも躊躇されます。そこで今回はAPIがレガシー化しないための方法を紹介します。 常に手を加え続ける APIは一度作って終わりではありません。むしろ放置してしまうと実装がどうなっていたのかを忘れがちで、半年や一年後にメンテナンスもできなくなります。その結果、メソッドを分けたりして、全体のバランスが悪くなります。 逆説的ですが、常にメンテ

単一のエンドポイントで、クライアント側で指定することで任意のデータを取得できるGraphQLですが、ビジネスで利用する際に必ず注意しなければならないのがセキュリティでしょう。GraphQLを利用、提供する上での注意点を紹介します。 認証 GraphQLではサーバサイドのデータベースのようにID/パスワードのような仕組みは用意されていません。他のAPIと同様に、認証技術と組み合わせることができます。例えばOAuth2であったり、トークン認証になります。これらは自分で実装する必要があります。 そのため、RES

APIはApplication Programming Interface（アプリケーション・プログラミング・インタフェース）の略語です。アプリケーションやシステムを開発するためのインタフェースといった意味になります。 今でこそWeb APIもAPIと呼ばれたりしますが、元々APIというのはデスクトップアプリケーションで用意されている仕組みでした。例えばExcelを外部プログラミングから呼び出してデータ入力や出力をさせたり、プリンタドライバを呼び出して印刷処理をするといった具合です。これらはWindows

LIFULL HOME'S事業本部 技術開発部 の冨田です。 LIFULLエンジニアのインタビューを通して、なかで働くエンジニアはどんな人なのか、どんなことをしているのか、を知ってもらうきっかけになればと思い、このような取り組みを始めました。 ゲスト紹介 本日のゲストはおなじく LIFULL HOME'S事業本部 技術開発部 の磯野さんです。 過去には iOSアプリのLIFULL HOME’S やオンプレミスからクラウドへのサーバ移行、 Zipkinの導入 なども担当され、現在はLIFULL

企業間におけるAPI活用が進んできています。クラウドベンダーの提供するAPIに限らず、これまでAPIを提供してこなかったような企業でもAPIを使ってビジネス拡大を図るケースが増えています。 そこで今回は企業がAPIを公開することで得られるメリットについて紹介します。 自社技術をブラックボックスにしたまま利用させられる どのような企業であっても自社独自の技術を無闇に公開したいとは思わないはずです。特に特許が絡んでいたり、自社のコア技術であれば尚更でしょう。しかし技術を持っていることや、それを新しい収益源とし

APIは外部リソースからデータを取得して他のデータと合わせて自分たちのサービスに付加価値を追加できますが、同じように外部からデータを取得する手法としてスクレイピングが知られています。今回はスクレイピングとAPIの違いを紹介します。 スクレイピングとは？ スクレイピングはサーバサイドのプログラミング言語を使って外部サーバへアクセスし、そのコンテンツから自分たちの欲しい情報を引き出す手法です。多くはHTMLを返す場合に使われ、DOMを解析したり正規表現を使ってデータを抜き出します。 スクレイピングはサービスが

ここ1、2年くらいで注目が集まっているのがマイクロサービスと言われるシステムアーキテクチャです。今回はそんなマイクロサービスの特徴を紹介します。 小さくシステムを定義して組み合わせる マイクロサービスはその名の通り、小さな（マイクロ）サービスに特化したアーキテクチャです。例えば認証/ユーザ管理や決済など特定の機能に特化した部分を一まとめにして構築します。バックグラウンドのデータベースについては共通化されていたり、クラスタリングを組んで参照については個々のマイクロサービスでデータベースを持っている場合もあり

APIは自動処理であるという点において、セキュリティリスクの大きい技術と言えます。もし認証情報が漏れると、次のようなリスクが起こりえるでしょう。 データを一気に消される プライバシーや機密に関わるデータを一気に抜かれる 違法なデータをアップロードされる 不要なデータが大量に送られる そうした状態を防ぐためにもセキュリティについて十分な配慮が必要です。 1. アクセス制限をかけましょう 企業同士の提携によるAPI利用の場合、IPアドレス単位でアクセス制限しても良いでしょう。そうすることで提携先の企業からの正

APIの利用者が増えないという悩みは良く聞くところです。そのために行いたい施策を紹介します。 1. インタフェースを他と合わせる もしすでに同分野においてAPIが存在するのであれば、そこに合わせたAPI設計を選択するという手があります。あえて独自性を貫くのは、あまり良い選択肢ではありません。開発者にとっても似たAPIは乗り換え対象にもなるので、全く別な構成よりは似ている方が手軽と言えます。 ただしGoogleとOracleの裁判で見るように、APIにも著作権が認められようとしています（最終的な判決は執筆時

APIは“Web API”と呼ばれることが多いので、Webアプリケーションと関係が強いと感じられるでしょう。しかしAPIの活用される場所はWebだけに留まらなくなっています。その一つがスマートフォンアプリです。 iOS/Androidを中心としたアプリストアでは300万を超えるアプリが登録されています。この殆どがネットワーク機能を使っており、それらのネットワーク機能はAPIを利用しています。今回はそんなスマートフォンアプリとAPIの関係について紹介します。 多くがプラットフォームまたはプライベートAPI

Enterprise APIs Advent Calendar 2015 への記事です。 大学や専門学校ではもちろん、最近では小中学校においてもICTの活用が進んでいます。 ICT活用事例として代表的なものにeラーニングがありますが、eラーニングの仕様については国際的な標準規格が存在し、今日はその一つであるExperience APIについてご紹介したいと思います。 Experience API(旧称：Tin Can API) eラーニングの仕様についてはSCROMという国際的な標準規格が、米国のADLと