POSTとPUTの使い分け : アジャイル株式会社
GET はもともと副作用がないメソッドとして定義されており、あるURIに対して、何度GETを繰り返してもリソースの状態は変化しない事が保証されています。 DELETE も GET に次いで判りやすいでしょう。一度削除しても、複数回削除しても、削除された状態が変わる事はありません＝べき等 POST と PUT はどうでしょうか？ リソースの新規作成で考える 例えば社員管理システムをRESTful Webサービスで作成する事を考えます。 社員リソースの URI は以下になります。 http://<サーバ名>/employee/<社員番号> 社員リソースの作成には以下のXMLを利用するとします。 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <employee> <firstname>太郎</firstname> <lastnam
RESTful API設計におけるHTTPステータスコードの指針 - Qiita
RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ
REST and microservices - breaking down the monolith step by asynchronous step | Red Hat Developer
A few days ago I had a rant about the misuse and misunderstanding of REST (typically HTTP) for microservices. To summarize, a few people/groups have been suggesting that you cannot do asynchronous interactions with HTTP, and that as a result of using HTTP you cannot break down a monolithic application into more agile microservices. The fact that most people refer to REST when they really mean HTTP
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
JWTUMOIM: Act 3
I'd say I've looked at about a hundred different web service designs. I've tried to design good web services. I want to distinguish between good web services and bad ones, and figure out what is the relationship between the constraints of REST and subjectively determined web service quality. I figured out about two-thirds of the answer while I was writing RESTful Web services. What I'm about to sh
リソースの一部更新におけるURL設計 - Qiita
概要 Webアプリケーションにて、リソースの一部更新を行う際、どのようにURL設計を行うとシンプルで美しいか（本当はそこまで考えていなかったけど）悩んでいたところ、 @t_wada さんから素敵な設計指針をご教示いただきました。 本記事はその内容に加えて、実際に自分で行ったこと、調べたこと、思った事など、まとめております。 あらすじ 数週間前にSIピラミッドからヒモなしバンジーを決めてWebの世界に飛び込んだ私は、小さな小さなWebアプリケーションをrails newから手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能をどう実装したもんかなーと悩んでました。以下、当時（といっても先週）の超雑なぼやき。 リンクをクリックしてモデルの一部を変更するのはどうしたらいいんだろう。 例）不参加をクリック -> 某カラムをtrueからfalseへ リクエストオブジェクトに対象カラムの
REST, where’s my state? | Ruben Verborgh
HTTP, the Hypertext Transfer Protocol, has been designed under the constraints of the REST architectural style. One of the well-known constraints of this REpresentational State Transfer style is that communication must be stateless. Why was this particular constraint introduced? And who is in charge then of maintaining state, since it is clearly necessary for many Web applications? This post expl
The S in REST
18 August 2014 REST is a vast improvement over complex things like SOAP and CORBA, but I think we still have a way to go before we’ve reached simple. REST is an acronym for REpresentational State Transfer, and I think the “state” part of that acronym gives rise to a lot of incidental complexity as systems grow. You can think of state as a combination of value and time, and in the RESTful case, the
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
RESTistential Crisis over Hypermedia APIs
Scaling Challenges: Productivity, Cost Efficiency, and Microservice Management The main objective of this article is to delve into the technical complexities and strategic adjustments undertaken by Trainline. By examining challenges such as managing peak transaction volumes and orchestrating microservice architectures, we aim to uncover the valuable lessons learned and insights gained from Trainli
API Exchange
Please note: GSMA’s Federated Discovery Service has ended – for more information please contact the team at [email protected]. The API Exchange enables operators to federate between their individual APIs to deliver cross-operator reach. API Exchange: Global API Federation capability The API Exchange: Reach and Flexibility The API Exchange serves to bridge the gap between application providers’ nee
REST Commander: Scalable Web Server Management and Monitoring
REST Commander: Scalable Web Server Management and Monitoring In the era of cloud and XaaS (everything as a service), REST/SOAP-based web services have become ubiquitous within eBay’s platform. We dynamically monitor and manage a large and rapidly growing number of web servers deployed on our infrastructure and systems. However, existing tools present major challenges when making REST/SOAP calls w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Is REST DELETE really idempotent?
What is the appropriate HTTP response code to a successful DELETE request?
DELETE is for Saying Goodbye
What Is Idempotent in REST?
RESTful design: when to use sub-resources?
REST - supporting multiple possible identifiers
Open Mobile Alliance - Specifications
GitHub - axsh/sinatra-browse: Parameter declaration framework and browsable API for Sinatra
