Webはインターネットになった - naoyaのはてなダイアリー
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Inclusive Technology Consulting - Bocoup
Building a back-end API layer introduces a whole new layer of coordination between server and client code. While there are many aspects to this delicate dance of communication, one key ingredient to minimizing back-and-forth-confusion-about what-call-does-what, is consistently communicating about your API endpoints. This is by no means rocket science, but over time I’ve created a template that I n
RailsでのURL設計を考えてみる(5) Railsのリソースパターン - ぶろぐ。@はてな
URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。 今までのシリーズ記事と重なるところもありますが、まとめということで…。 リソースとは 簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。 http://d.hatena.ne.jp/tkawa/20110819/p1 http://d.hatena.ne.jp/tkawa/20110819 最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。 その次は、『tkawa
RailsでのfavoriteのURL設計 - ぶろぐ。@はてな
http://d.hatena.ne.jp/r7kamura/20110505/1304577667がすごいなと思って、routes.rbの書き方の例についてコメントしたのですが、自分で書いておいて後で「unfavorite」はちょっとまずいかなと思ったので、favorite（いわゆるお気に入り、スター）はどういうふうに設計すればいいのか考えてみました。 構造はよくある感じの、 tweet has_many favorites user has_many favorites 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 ブログのコメントにはこのように書きました。 (1) resources :tweets do member do post 'favorite' post 'unfavorite' end end ルーティングは
REST-ful URI design | 2PartsMagic Blog
This post is about URI naming. Designing URI names. Some tips and rules and conventions that you can follow when figuring out your application's URIs. TheThis post is about URI naming. Designing URI names. Some tips and rules and conventions that you can follow when figuring out your application’s URIs. The focus is on URIs for ‘REST-ful’ applications. But many of the tips apply to any kind
RESTful Web アプリの設計レビューの話
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
なにかが抜けている -- Webと関わる人間はどこにいる？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
winplusさんが、色々と有意義な考察をなさっています。 http://d.hatena.ne.jp/winplus/20120716/1342407196 ： 「アプリケーション状態エンジンとしてのハイパーメディア」というのは、アプリケーション状態はすべてリソース(≠<リソース>)として存在しているため、リンクをつうじてリソース間を移動することがそのままアプリケーション状態の遷移となる、ということだと理解しています。 ここで、「リソース」と「<リソース>」が区別されていますが、「リソース」に関しては、次の説明で十分だと思います。 リソースにはぜんぶURLをつける。つまりURLでリソースを識別できるようにする。 このような解釈に対して疑問に思うことがあります。この疑問が解決すれば、「<リソース>」から「リソース」に乗り換えてもいいと思っています。 [追記]「人間はどこにいる？」という見出
HTTP/2 Expression of luke-warm interest: Varnish from Poul-Henning Kamp on 2012-07-12 (ietf-http-wg@w3.org from July to September 2012)
From: Poul-Henning Kamp <phk@phk.freebsd.dk> Date: Thu, 12 Jul 2012 23:48:20 +0000 To: HTTP Working Group <ietf-http-wg@w3.org> Message-ID: <41677.1342136900@critter.freebsd.dk> This is Varnish' response to the call for expression of interest in HTTP/2[1]. Varnish ------- Presently Varnish[2] only implements a subset of HTTP/1.1 consistent with its hybrid/dual "http-server" / "http-proxy" role. I
ハイパーメディア・アプリケーションをどう捉えればいいのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
先週は、URLやらハイパーリンクやらの話をしてました。僕の用語法がどうも杜撰〈ずさん〉で誤解を招いたキライがあります。言葉の説明を付け足しながら、少し抽象的に、「ハイパーメディア・アプリケーション」をどう捉えればいいのか？ これについて述べたいと思います。 内容： 基本的な概念 クラアント側の状態遷移 状態遷移系のチャンキング 半遷移族から状態遷移系の構成 ハイパーメディア・アプリケーション 基本的な概念 「Webアプリケーション」、「Webサイト」、「Webサービス」、「Web API」とか、これらの言葉を区別するのは面倒なので、僕は区別してません。しかし、それぞれの言葉に特有の意味を想定している人もいるでしょうから、総称的に「Webシステム」ということにします。 Webシステムの基本は、HTTPによるリクエストとレスポンスです。レスポンスで返されたデータにハイパーリンクが含まれないよう
RESTに関する３つの間違い
楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Home
Apigee API Management
Microsoftが新しいREST APIフレームワークを発表
InfoQ: How to GET a Cup of Coffee
紹介：Restful Objects
GitHub - bploetz/versionist: A plugin for versioning Rails based RESTful APIs.
