なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
REST における PUT メソッドと POST メソッドの違い - 星一の日記
最近 REST に関する本を読んでいます。統一された少ないルールで、さまざまな Web アプリケーションを表現できるというのは、妄想が膨らんでワクワクしますね。学んだことをメモがてらに書きます。 RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行本購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る PUT も POST も似た役割をもつメソッドです。両方ともリソースの新規作成または更新を行います。この二つのメソッドは何が異なり、どのように使い分けるべきなのでしょうか。 リソースの新規作成 まずリソースの新規作成について。 PUT は URI が指し示すリソースを直接作成することを、サーバーに要求します。たと
HTTPの間違いやすい点: akiのお部屋
Web開発者はHTTPについて知らない（Webを理解してないWebアプリ開発者）ということを書いたんですが、HTTPを簡単に言ってしまうと、リソースに対するCRUDについての取り決め（プロトコル）です。本来はW3CのRFCを読むのが良いんですが、以下のサイトが非常によくまとまっていて読みやすいです。 Studying HTTP で、HTTPの細かいところの言及は避けるとして、aki的には、このHTTPを利用するときに間違えやすい点をまとめていこうと思います。 ①リソースにURIを割り当てていない リソースというのはURI（Uniform Resource Identifier）というIDで一意に識別されます。 1つのURIに複数の意味を持たせ、渡すパラメータ（クエリーストリングなど）でリソースを識別しようとすることです。 例えば、こんな感じ /resources?type=entity&i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Element
