You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
概要 最近は API Blueprint で仕様書を書くことが多かったのですが、Swagger が世界標準になるかもしれない、ということもあり、開発の効率化を進めるためにも概要をまとめてみようと思った次第です。 Swaggerとは Swagger は RESTful APIを構築するためのオープンソースのフレームワークのことです。「Open API Initiative」という団体がRESTful APIのインターフェイスの記述をするための標準フォーマットを推進していて、その標準フォーマットがSwaggerです。Swaggerには多くの便利なツールが提供されていることもあり、多くのメリットを享受できそうです。 Swagger Spec を書いておけば自動的にドキュメント生成までしてくれ、それだけではなく、ドキュメントから実際のリクエストを投げられる優れものです。 Swaggerのツール群
When designing your first REST system there are a variety of mistakes people often make. I want to summarize them so that you can avoid them. If any are unclear, ask for more information on rest-discuss. Using HTTP is not enough. You can use HTTP in a Web service without SOAP or XML-RPC and still do the logical equivalent of SOAP or XML-RPC. If you're going to use HTTP wrong you would actually be
Cloud/SaaS Architecture, Engineering, and Deployment I noticed that Flickr had some pretty sweet URIs, but I wanted to find out exactly what it was that made them good. To brush up on URI design, I scoured this great list of resources compiled by Tanya Rabourn: The User Interface of URLs (Paul E. Hoffman, 1995) Cool URI’s Don’t Change (Tim Berners-Lee 1998) URL’s as UI (Jakob Nielsen, 1999) URL’s
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: High Speed Internet Anti Wrinkle Creams Credit Card Application Best Penny Stocks fashion trends Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
RESTful なアプリケーションでは、対象とするリソースに副作用を及ぼすときは POST なり PUT を使うのがベストプラクティス。(ベストプラクティスという言葉を使ってみたかった!) この考え方はウェブアプリケーションを作るときに、GET にするか POST にするかに明確な指針を与えてくれてすっきりします。 で、ふと思ったんだけど、表面的には GET でよさそうだけども実は中でリソースに副作用が及んでいるような代物はどうしたらいいんだろうなということ。例えば検索エンジンなんかで、クリックに合わせて後ろでクリック回数を数えてたり統計とってたりするものがあると思うんだけど、そういう類。 ウェブサイトの検索エンジンとかだとクリック対象の URI が差すリソースが外部サイトでちょっとイメージしづらいので、例えば search.cpan.org など。モジュールの検索結果からのクリック回数を
Authenticating REST Requests
Authenticating REST Requests Every non-anonymous request to S3 must contain authentication information to establish the identity of the principal making the request. In REST, this is done by first putting the headers in a canonical format, then signing the headers using your AWS Secret Access Key. There are two ways to send your signature with a request. The first is to put your AWS Access Key ID
yohei-y:weblog: 良い URI の設計
URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは 変らない(don't change) 人間が推測可能(are human guessable) 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem)) サイト構造をビジュアライズするのに役立つ(help visualize the site structure) 短い(are short) 小文字を使う(use lowercase) 予期されない記号を使わない(don't use unexpected punctuation) 問合せパラメータな
■ Apple新製品 iPod Hi-Fi、ダセぇ。これがApple製品だなんて信じらんない。他社製品が間違って紛れ込んだんじゃないのか。 Mac miniは、相変わらずちょっと欲しい。やはり小さい機械には惹かれる。これでWindowsが動けばなぁ(←だいなし)。 ■ おれだったらフォト蔵APIをこうする せっかくユーザでもあるので(携帯のバックアップにしか使ってないけど)、β公開されたフォト蔵API(アナウンス)を使ってみることにした……んだけど、概要を読んで「ちょっと待て」と思った。 フォト蔵APIは全てRESTで提供されています。機能毎の個別のURLに対して必要なデータをPOSTします。結果は全てXMLで返ってきます。 えーと、GETを使うべきAPIでもPOSTですかね。それ、RESTじゃなくてただの「なんちゃってRPC」だし。……とは言ったものの、自分だってRESTを理解しているか
yohei-y:weblog: REST は難しい、だからこそ面白い
知り合いに教えてもらって知ったのだが、今月の日経ソフトウエアは Web プログラミングの特集である。 ちょっと立ち読みしたところ、内容は Web 2.0 まわりの記事だった。 その特集の中の囲み記事で REST と僕の名前が出てくるところがある。 「わかりづらい REST という言葉」というタイトルで、 REST がアーキテクチャスタイルであること、 一方で REST API は「ホームページ」のような誤用であるが、そちらの方が一般的になってしまっていること、 が簡単に記述されていた。 REST == HTTP GET+XML のような紹介よりも1万倍よかったし、 何よりこういう初心者向けのメジャー(?)な雑誌記事で REST に言及するよ うになって、本当によかったと思う。1年前には考えられなかったことだ。 ただ、気になったのは REST が難しくてわかりづらい、という話だ。 そりゃ確か
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
yohei-y:weblog: Atom で件数取得
なんか催促されちゃったみたいなので :-) 詳しく書いてみます。 はてなのブックマーク件数取得 API いいですね。 今さら xml-rpc かよ! というツッコミは置いておいて、 データ重要な世の中で有用なコンテンツ(メタデータ)にリーチする 方法が増えるのは喜ばしいことです。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義できるのか。教えて偉い人! 偉い人じゃないけど、結論からいえば、 Atom Publishing Protocol (APP) そのままじゃ無理です。 やってもいいけどどうしても無理が出てしまいそう。 そもそも目的が違うのだから、ここは野良 XML/プロトコルでいいのでは。 ただ、結果をフィードで取れるとそれなりに嬉しいかもしれない。 普通 REST で検索するときは query string を使っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
