翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
InfoQ: RESTfulアプリケーションにおけるハイパーメディア
アプリケーションの状態は、「セッションの状態」という名でも知られ、RESTの「ステートレス」な制約によって表される状態の一つでもあります。そして、それはクライアントが単独で保持する必要があります。対照的に、VNCやWindowsのリモートデスクトップといったリモートセッション技術を使用しているならば、アプリケーションの状態はサーバー上で完全に保持されます。 「ハイパーメディア」という言葉は、「ハイパーテキスト」(彼の発案です)を一般化するものとして1962年にTed Nelson氏によって発案されました。ハイパーテキストがテキストドキュメントのリンクを含んでいるのに対し、ハイパーメディアは、その範囲を全てのメディア形式に拡張しました。当然、両者の主要ポイントは、私たちが使用する内容にリンクが埋め込まれているということです。 制約の実例 REST は、2003/2004年にインターネット関連
制約に従いながらもHTTPを自由にするRESTful――『JavaによるRESTfulシステム構築』：晴読雨読＠エンジニアライフ：エンジニアライフ
JavaによるRESTfulシステム構築 Bill Burke（著） arton（監修） 菅野良二（翻訳） オライリージャパン 2010年8月 ISBN-10: 4873114675 ISBN-13: 978-4873114675 3360円（税込） REST（Representational State Transfer）はアーキテクチャスタイルの1つである。RESTfulとは、RESTの制約に従ってRESTらしい振る舞いをするシステムを指し示す。英語の語感はよく知らないが「RESTらしく」とか「RESTのように」というニュアンスでよいのだと思う。それでは、RESTとは何だろうか。 Roy Fieldingは、HTTPプロトコル規格の策定に尽力した1人である。彼の著した博士論文の中で、RESTという概念は提唱された。 Webがこんなにも普及している理由は何か？ Webをスケーラブルにして
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
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の誤解：CRUDはRESTじゃない！ - 杉風呂2.0 - A Lifelog -
以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。本人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
RESTに対する７つの誤解
海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT
SOAの未来はRESTか
最も単純な場合、サービスは必要なものをすべて含んだ、独立して開発、配置、管理、メンテナンスができるソフトウエアの実装であり、企業の特定のビジネスと関係のある機能をに提供し、設計によって"統合可能"である、と言えます。ある“サービス”は動詞で定義できます(例えば、“顧客の信用度を検証する”、というふうに実現する機能を表現します)。 サービスはプログラミングの構成概念ではありません。APIのセットでもありません。むしろ、企業の問題解決のために実装される、設計物(部品の設計、実装、メンテナンス)と配置物です。サービスの機能性はサービスのインターフェイス(そのサービス特有の)によって定義されます。このインターフェイスは複数の実装方法で実現できます。サービスのインターフェイスを定義するにはふたつの基本的な方法があります。RPCスタイルとメッセージングスタイルです。RPCスタイルの実装はサービスの起動
RESTはエンタープライズで成功しているか？
原文(投稿日：2011/06/01)へのリンク Programmable Webのデータによる、APIの73％が RESTfulであることを基に、RESTは勝利した、と早合点する人達がいるかもしれない。しかしSOAの実践者である Steve Jones氏は、それらのAPIはデータ収集するフロントエンド システムで使われており、エンタープライズ システムの大部分によっては使われていないし、RESTはまだエンタープライズに対応出来ていない、と注意喚起している。 Masheryの前CTOであるClay Loveless氏は、Glue Con 2011で「SOA失敗の教訓」という講演の中で、APIリソース索引作成のProgrammable Webによる統計について話し、ここ数年SOAPは伸びているが、堅実に伸びているRESTに比べてずっと割合が小さいことを示した。 これらの数値に対して、Capge
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめ
RESTを自称してはいけない
Web API Design - 開発者が愛するインターフェイスを作る
GR8 Conf Grails presentation
RESTful Web アプリの設計レビューの話
SOAP から REST へ - その方法と意義
[REST] 認証が必要な API を REST っぽく作るときのメモ - それはBooks
REST APIで更に問題が？
REST APIの良い、悪い、醜い
アプリケーションのRESTful度合いをどう計測するか