Azure Storage REST API Reference
The REST APIs for the Microsoft Azure storage services offer programmatic access to the Blob, Queue, Table, and File services in Azure or in the development environment via the storage emulator. All storage services are accessible via REST APIs. Storage services may be accessed from within a service running in Azure, or directly over the Internet from any application that can send an HTTP/HTTPS re
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
JSON on HTTPやWeb APIを各言語でどうやって実装するのか
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
RESTに対する７つの誤解
海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT
たかが URI の設計、されど URI の設計 | システム設計日記
関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。 GET /リソースの識別名(URI) をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。 ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「ＵＲＩ」を「識別キー」という言葉にしている。 実際に、HTTP を使うかどうかは別として、 ◎ リソース（＝関心事オブジェクト）の ◎ URI (＝識別キー) を指定して ◎ 現在の状態(current state)を入手する というのは、エンタープライズアプリケーションの基本価値のひとつですね。 「関心のあることを知る」という業務の基本ニーズ。 このニーズに応えるための GET 方式のモデリング・設計は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTful Web アプリの設計レビューの話
