続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい＆メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例
モバイルAPIデザインのまとめ - ワザノバ | wazanova
Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアのAPI議論」で紹介しました。）とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
日本の全エンジニアに捧ぐ！現在公開されているAPI一覧【2013年版】 | Find Job ! Startup
2013年のいま、API界隈が熱い！ 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します！ HOT! API 総務省 次世代統計利用システム（国勢調査、人口推計、就業構造、企業統計、物価統計 etc.） NHK番組表（※未公開） 行政・自治体・公共サービス 郵便番号 郵便番号検索API（郵便番号 → 住所） 郵便専門ネット（郵便番号 → 住所、郵便番号の簡易存在チェック） ぽすたん（郵便番号 → 住所、住所 → 郵便番号） IW3 PROJECT（郵便番号 → 住所、住所 → 郵便番号） 宇宙 Google+ JAXA PR（※現在一部の学生に限定公開
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
Twitter 検索API メモ - 超自己満足プログラミング
【2010-02-28 追記】 いつの間にやら結構な数のブックマークをして頂いて、 情報が古いままでは心苦しいので、１年ぶりくらいになってしまいましたが、情報を更新しました。 思ったほど変更はなかったのでよかったです。 〜〜 ここから元々の本文 〜〜 http://apiwiki.twitter.com/Twitter-API-Documentation の「Search API Methods」について のメモですが、 英語がかなり苦手なので、間違ってるとこもあるかもしれません。 あと、大してtwitterを使ってなかったりするので、 twitterの機能面でよくわかってない部分もあります。 検索API : http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search 出力形式 AtomとJSONに対応。リクエストURLはそ
Twitter APIのsince_idの仕様を勘違いしていた… - 風柳メモ
この記事は REST API version 1 時のものです。 REST API version 1.1 ではGET statuses/user_timelineの仕様自体が変更となっていますので(例えばpageオプションはなくなっている等)、この記事は参考にはなりません。ご注意ください。 statuses/user_timeline APIを使って、特定ツイートの前後のツイートを取得する動作をさせようとして、since_idオプションの仕様を勘違いしていたことに今更気がついたので、覚書ついでに恥をさらしておきます。 max_idの仕様は直感的なんですよね 特定ツイート以前(直前)のものを取得するのはとくに問題無くて、 max_id. Returns only statuses with an ID less than (that is, older than) or equal to
Twitter API v1.1におけるSearch APIのRate Limit - F.Ko-Jiの「一秒後は未来」
先ごろ Twitter API のバージョン1.1が公開されましたが、個人的に気になっていたのが Search API の Rate Limit です。 Twitterが公開しているドキュメント「REST API Rate Limiting in v1.1 | Twitter Developers」には「15 Minute Windows」という新しい単位みたいなものが登場しています。 Rate limits in version 1.1 of the API are divided into 15 minute intervals, which is a change from the 60 minute blocks in version 1.0. 簡単に訳すと「これまで60分単位のブロックだった Rate Limit が15分単位になる。」という意味。 While in versio
疎結合と MVC と JSON API とオーバーヘッドと非同期とレスポンスタイムに関する適当な考察 - punitan (a.k.a. punytan) のメモ
最近考えていることを話す機会があったので文章にしてまとめてみる。 疎結合 昨今の複雑化するウェブアプリケーションを効率的に開発するにあたって、疎結合な設計にすることは開発／保守効率を上げるためには必須の条件となることは経験上嫌というほど皆が経験している。（このへんの感覚がわからない人は一度疎結合なアプリケーションを書いてみると良い） 疎結合な設計をすることで問題の切り分けが容易になり、自動化されたユニットテスト・コンポーネントテスト・ UAT が手元の MacBook で実行でき、高いカバレッジに助けられて臆すること無くコードに手を入れられる環境を入手でき、開発する上でストレスなく障害も少ないというメリットが享受できる。 話を戻して、疎結合な設計の例をみると、ウェブサーバとアプリケーションを分離することであるとか、 MVC であるとか、良質かつ単体で動く小さなモジュールを組み合わせて書くと
JSON on HTTPやWeb APIを各言語でどうやって実装するのか
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
未公開の Google Reader API を探る - WebOS Goodies
先日、大幅にアップグレードした Google Reader ですが、その API を独自に解析されているページを見つけました。もっとも、「Google Reader API」でググるとトップにくるページですので皆さんご存知かもしれませんが。 http://www.niallkennedy.com/blog/archives/2005/12/... ※リンク先は 2005 年 12 月とだいぶ古い記事ですのでご注意ください。 とても興味深い内容ですし、軽く探しただけでは日本語の資料は見当たらなかったので、今日はこのネタを書いてみることにします。プログラミングカテゴリへの引越し第一弾の記事としても適当なのではないかなと（＾＾ゞ。それでは、上記の記事で解説されている API を個別にご紹介していきます。 フィードの取得 Google Reader API は、基本的に通常の HTTP リクエスト
外部APIを含めたWebアプリのテストをしてみる - Perl勉強メモ アルパカDiary出張版
外部APIを用いたWebアプリのコントローラテストについて。 たとえば 数値の２乗を結果として返すAPIサーバ があるとして、 そのAPIを利用した結果をHTMLとして出力するアプリケーション を考えてみます。 しかし、このように外部APIサーバを用いるとテストが難しくなります。 もしかしたらアクセスコントロールされているかもしれませんし、 メンテナンスされているかもしれませんし、 オフラインだとそもそもテストできないですよね！ そこで外部APIサーバを振舞うplackサーバをローカルで立ち上げて それをproveで利用できるといいかも。 というわけでそのような環境を作ってみます。 サンプルWebアプリ *1 まずは /api に アクセスすると 外部APIサーバにアクセスしてその結果を返すだけのコントローラを書いてみます。 $host はテストからコントロールできるように環境変数をみてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
wikihub.io
yjap.md
WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめ
ゆーすけべー日記
ゆーすけべー日記
アクシスコミュニケーションズ - ネットワークカメラおよびその他IPネットワークの構築ソリューション分野を牽引する企業 | Axis Communications