PUT か POST か PATCH か？ - Qiita
CRUDの操作をRESTで表現すると一対一で対応していないことに気づきます。RはGET、DはDELETEと考えておいて良さそうですが、CとUはPUT、POST、PATCHの3つの選択肢があり、APIを設計していると迷います。整理するためにまとめておきたいと思います。 下記の資料を参考にしました。 http - PUT vs POST in REST - Stack Overflow When to use PUT or POST | - The RESTful cookbook GitHub API v3 基本的な考え方 PUT: リソースの作成、リソースの置換 POST: リソースの作成 PATCH: リソースの部分置換 PUTはPOSTと違い、リソース名を指定して作成または更新をかけるメソッドです。PUT /articles/3421は新規作成かもしれませんし、更新かもしれません。PU
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTf
REST における PUT メソッドと POST メソッドの違い - 星一の日記
最近 REST に関する本を読んでいます。統一された少ないルールで、さまざまな Web アプリケーションを表現できるというのは、妄想が膨らんでワクワクしますね。学んだことをメモがてらに書きます。 RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行本購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る PUT も POST も似た役割をもつメソッドです。両方ともリソースの新規作成または更新を行います。この二つのメソッドは何が異なり、どのように使い分けるべきなのでしょうか。 リソースの新規作成 まずリソースの新規作成について。 PUT は URI が指し示すリソースを直接作成することを、サーバーに要求します。たと
Redmine REST API - r-labs - Redmine
ステータスの凡例 : Stable - 仕様機能は完成されていて、今後の大きな変更は予定されていません。 Beta - まだバグが残っているか、いくつかの細かな機能が実装されていません。 Alpha - 主要な機能は出来てますが、まだ API 使用者からのフィードバッグを必要としています。 Prototype - 試験的な運用のためにざっと実装されただけで、今後大きな変更が加わる可能性があります。 本格的に使用するのはお勧めできません Planned - 将来のバージョンで予定されているもので、いつになるかは開発参加者しだいです。 各データ共通¶ ユーザー認証¶ ほとんどの場合、 API では認証を必要とします。 API 型式での認証を可能にするためには 管理 → 設定 → 認証 の順で設定ページを表示した後、 [REST による Web サービスを有効にする] にチェックを入れます。 そ
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
yohei-y:weblog: 『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました
このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山本 陽平技術評論社 2010-04-08 この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。
「Webを支える技術」。Webアーキテクチャを知り、Webサービスを設計するための一冊
日本にREST（Representational State Transfer）と呼ばれるWebのアーキテクチャスタイルを広めた山本陽平氏から、「本を出版するので送りたい」という連絡をいただいたのが約1カ月前。送られてきたのがこの本「Webを支える技術」でした。 山本氏のブログを拝見すると、約1年ほどはこの本の執筆に取り組んでいたご様子。中味を読んでみればそれも納得です。 本書はWebを支える3つの技術、HTTP、URI、HTMLを中心にWebのアーキテクチャを詳しく解説することから始まり、Webのアーキテクチャに沿ってWebアプリケーションや（広義の）Webサービスをどう適切に設計していくべきなのか、という、Webアプリケーションを開発するときに必ず考慮しなければならない課題を解決する道筋を教えてくれます。 Webアプリケーションをどう設計するべきか、大事なことなのに、これまでこれほど十
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
