RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
InfoQ: ErlangとYawsを使ったRESTfulサービス
以前に有名となった「Apache vs Yawsのグラフ」(source)を見て、あなたもまたYawsを使うべきだと思ったでしょうか? 一見すると、そのグラフは、Yawsに対する信じられないくらい大きなスケーラビリティの優位性があるように見えます。Apacheが4000のパラレル接続でダウンしたのに対し、Yawsは80,000を超えるスケール能力を持っています。このグラフに対する反応は大きく二極化する傾向にあります。「これらのグラフは正確な方法で行われたものではなかった」あるいは「Apacheの設定ミスに違いない」というものと、それとは反対に「ワオ！Yawsを利用する価値がある」というものです。 Yawsの比較グラフを信じるかどうかに関係なく、Yaws(サイト・英語)は動的コンテンツを提供するための確かなWebサーバーです。Claes Wikstrom氏は、Yawsを「もう一つのWebサー
RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
