2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
空気を読んで年齢を答えてくれる例のあれの裏側にあるAPIがAzure Marketplaceに登場してきました。 - はつねの日記
Face APIっていうらしいですよ。 Marketplaceからの購入 でも、お高いんでしょう？ ふ、フリーっ！ 無料ですか！ 米国西部にしか展開できませんがさくっと作成できます。 管理用キーの取得 作成が完了するとAzureダッシュボードに「Microsoft Webサイト」にアクセスが必要だとリンクが張られているのでリンク先に移動します。 https://dev.projectoxford.ai/Developer API仕様 Face APIには次のようなエンドポイントが公開されています。 Detection Find Similar Faces Grouping Identification Verification Face APIのページ（というかProject Oxfordのページ) には各エントリポイントを試せる「Open API Testing Console」が用意
金勘定のためのBigDecimalそしてMoney and Currency API
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
Developers.IOが更新されたらYoするDEVIOを作った | DevelopersIO
はじめに 皆さん、Yoしてますか？ 相手にYoを送りつけるだけの不思議なソーシャルネットワーク「Yo」ですが、皆さんいまいち使い道のわからないまま、Yoが来たら機械的にYoを返すような状況になっているのでは無いでしょうか。しかしYo APIを使えば様々なアプリケーションが作れる...ということで世の流行から周回遅れもいいとこなんですけど、Yoを使って本ブログ「Developers.IO」が更新されたらYoを送るだけのスクリプトを書いてみました。 ソースコード #!/usr/bin/ruby require 'rss' require 'net/http' YO_API_TOKEN = "edit_your_api_token_strings" def rss_yo(url) lastupdate = Date.new rss = open(url) do |data| RSS::Parse
Railsが時代に合わなくなってきた - Qiita
追記 RailsでJS辛い問題に関しての結論：http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptがRailsから独立している Railsはとても堅牢。 モデル、コントローラ、ルーティングと、変にいじらない限りはほとんどテストが要らない。 必要なのは、モデルに新たにpublicメソッドを付けたときくらいだろう。 実際、バックエンドはそうそうバグが出ない。
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
日本の全エンジニアに捧ぐ！現在公開されているAPI一覧【2013年版】 | Find Job ! Startup
2013年のいま、API界隈が熱い！ 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します！ HOT! API 総務省 次世代統計利用システム（国勢調査、人口推計、就業構造、企業統計、物価統計 etc.） NHK番組表（※未公開） 行政・自治体・公共サービス 郵便番号 郵便番号検索API（郵便番号 → 住所） 郵便専門ネット（郵便番号 → 住所、郵便番号の簡易存在チェック） ぽすたん（郵便番号 → 住所、住所 → 郵便番号） IW3 PROJECT（郵便番号 → 住所、住所 → 郵便番号） 宇宙 Google+ JAXA PR（※現在一部の学生に限定公開
結局、Twitter API 1.1で何が変わる？ 5つのポイント
結局、Twitter API 1.1で何が変わる？ 5つのポイント：Twitter APIと開発者規約変更のインパクトまとめ 変更による影響範囲や、一部APIの廃止、レートリミット方式の変更、アプリケーション当たりのユーザー数、ツイート表示方式の厳格化などを5つのポイントにまとめて解説 開発者のはしご外し？ Twitter API狂騒曲 Twitterは2012年8月から9月にかけて開発者向けのブログで、APIや開発者規約の変更を立て続けにアナウンスしました。一部APIの廃止やレートリミット方式の変更、ツイート表示方式の厳格化など、影響は多岐にわたり、物議を醸しています。 Changes coming in Version 1.1 of the Twitter API Current status: API v1.1 Sunsetting @Anywhere Twitter、サードパーティ
自社サービスの機能を簡単にAPIで提供出来てしまう！gem doorkeeperが凄い。 - @camelmasaの開発日記
自社サービスにAPIを実装する事ってあまりないですよね。 kamadoのプロダクトも現在はAPIは公開してません。 もし提供するのであれば、簡易的な方法ですが、ユーザーテーブルにtokenカラムを追加して、API用のルーティングを作成する…という方法が考えられると思います。 しかし、その実装時間でより良いAPIが実装出来るとしたら素晴らしいですよね。 そこで紹介したいのがgem doorkeeperです。 日本語の記事が見当たらなかったので記事にしました。 github https://github.com/applicake/doorkeeper gem doorkeeperってどんな機能があるのか？ 簡単に説明すると、 ・アプリケーションの管理機能 ・アプリケーションの承認管理 ・スコープの設定 いってしまえば、Facebook API(に近い実装)そのまま実装出来ます。 しかもOAu
Facebook、「Notifications API」のβ版公開 － ＠IT
2012/09/04 米Facebookは8月31日、開発者が自分のアプリのユーザーにショートメッセージを送信できる「Notifications API」のβ版を公開した。 Facebookの開発者ブログによると、同APIは開発者からユーザーに宛てて、大切なイベントや友人からの招待状、アプリに関するお知らせなどを通知する目的で利用できる。 開発者がユーザーにメッセージを送るに当たって追加のパーミッションを取得する必要はない。一方、ユーザー側ではアプリからの通知を何通か受け取った後に、受信を拒否したいかどうか尋ねる画面が表示され、拒否または許可の選択が可能。オプトアウトの選択はいつでもできる。 テストの結果、アプリから質の高い通知を受け取ったユーザーはクリックスルー率が5～10倍になる半面、質の低い通知を送られたユーザーは通知機能を無効にしてしまう傾向があることが判明したという。 利用状況解
Twitter REST API：ダイレクトメッセージ関連｜Twitter関連｜Web関連特集｜PHP & JavaScript Room
direct_messages.xml<?xml version="1.0" encoding="UTF-8"?> <direct-messages type="array"> <direct_message> <id>1698907401</id> <sender_id>7948862</sender_id> <text>今日終わったら速攻呑みに行こー！</text> <recipient_id>55984769</recipient_id> <created_at>Tue Sep 28 05:06:10 +0000 2010</created_at> <sender_screen_name>cocoism</sender_screen_name> <recipient_screen_name>pjroomer</recipient_screen_name> <sender> <id>7
Twitter API で DM (ダイレクトメッセージ) の送受信に別途許可が必要になったので、その対応方法のまとめ - Yaks
Twitter API で DM (ダイレクトメッセージ) の送受信に別途許可が必要になったので、その対応方法のまとめ 2011年 5月 18日づけで Twitter の API を経由して DM を送受信する場合には別途アクセス許可を行う仕様に変更される、という公式のアナウンス (英語) がありました。 以前から API のアクセス権を細分化してほしいというリクエストが各方面で見られましたが、これに答える形での仕様変更としています。 具体的には、これまで API のアクセス権には Read and Write (情報の読み書き)、Read only (読み込みのみ) という 2パターンしかありませんでした。DM の操作に関してもこのアクセス権によって読み書き、または読み込みのみが行えていました。 ここに新たに Read, write and Private message という選択肢が
送信ダイアログ - シェア機能 - ドキュメンテーション - Meta for Developers
送信ダイアログにより、利用者は特定の友達にコンテンツを非公開で送信できます。リンクを非公開でシェアする方法には、Facebookメッセージという選択肢があります。送信ダイアログは、追加のアクセス許可を必要としません。 Facebookメッセージは人と人のコミュニケーションのためのチャンネルであり、アプリでメッセージを送信したり、友達への一斉送信を促したりするためのものではありません。基本的に、Facebook.comのゲームでは、ターン通知などのステータスの通信、アプリへの招待、複数の宛先へのメッセージ送信には、リクエストを使用してください。 通常のメールを送信するような状況において、代替として送信ダイアログを提供してください。 統合の例このダイアログをウェブサイトに追加するには、Facebook SDK for JavaScriptを使用して、URLへの完全なリダイレクトを実行します。モ
Facebook APIのつかいかた (OAuth 2.0) - Censorable log
FacebookのAPI、以外と日本にまとまった文献が少ない。 日本語版が少ないのと、コロコロ仕樣が変わっているせいだ。 「Facebook Connect API」なんかで検索しても、ぜんぜんいいページに辿りつかないので書く。 Twitterにくらべて、FacebookのOauth2.0 APIは、すごく簡単にできている。 Twitterもそうだが、「認証して見れるデータ」と「認証しなくても見れるデータ」の２種類がある。 認証しなくても見れるデータのほうが、セキュリティも低いし、入力もプログラムもカンタン。 ■認証しない系 たとえば、ぼくの基本情報は、 https://graph.facebook.com/hiroki.nakamura https://graph.facebook.com/●●●● こんだけ。 これで、基本情報がJSON形式で、充分とれる。 さらに、 https://g
AKB48で学ぶFacebookアプリとファンページの連携方法 - web探検隊
Facebookでファンページを作ったはいいものの、独自のコンテンツを提供しようとしたら、アプリと連携をさせたいところですよね。そこで、連携方法を調べてみました。ここで必要となるのはFacebookの 自分で開設したファンページ 自分で開発するアプリケーションとなります。連携することで、サーバーからファンページへ以下のような、自動投稿が可能になります。 ファンページを作るファンページの作り方はこちらのエントリーを参照してください。5月に書いたエントリーですが、それ程、変更されていません。アプリケーションを作るfacebook アプリの作り方・PHP 編（2010 年 10 月版）を参照して。マイアプリケーションのページから新規アプリケーションを作成してください → http://www.facebook.com/developers/apps.phpSanbox Mode ONにしておいた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger
IBM Developer
