RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
ツイッタ―のリツイート機能を使ったプレゼント企画って当たりあるの？
最近ツイッタ―をしていると、「リツイートしてくれると、抽選でプレゼント！」チラホラ見かけますよね。 でも、私としては自分が本当に抽選されているか、ちょっと懐疑的なんですよ。 その理由を記事にまとめてみました。 追記:当初「無理そう」と結論づけていましたが、「できそう」です。当初誤った結論を投稿していまい、申し訳ありません。 また、id:kw5様とid:tockthey様にはご指摘いただきありがとうございます。 Twitterでリツイートするだけでプレゼント抽選とは 見たことがある人ならわかるとおもいますが、ツイッタ―のタイムラインでこんなツイートを見かけるときがあります。 「プレイステーション4」 30台プレゼントします！ 応募方法は このツイートをリツイートのみ！ 当選連絡はDMで行うのでフォローだけお願いします。 ⬇︎因みにユーチューブでは100台プレゼントしてます⬇︎https://
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
登録されるとつらいユーザー名リスト - Qiita
Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc
Garage RailsでOAuth認証付きのRest APIをお手軽開発！
CookpadさんがOSSで先日OSSで公開されたGarageはRestfulなAPI + OAuth(Doorkeeper)をワンストップで提供してくれるgemです。 ちょうど触る機会が出てきたので、今回四苦八苦しながら使ってみたのでそのメモです！ 🎂 今回のサンプル実装今回はOAuthで認証して、次のシンプルなAPIにアクセスできるようにするまでのサンプルを作成します。 GET /v1/users => ユーザーのリスト出力 GET /v1/users/:id => 個々のユーザー情報の出力 🎃 Gemの追加Gemfileに以下を追加して、bundle install。 gem 'garage', github: 'cookpad/garage' gem 'responders', '~> 2.0' # If you use Rails4.2+ group :development
RubyKaigi 2014 で Hypermedia Web API について発表しました - ぶろぐ。@はてな
9月18日の RubyKaigi 2014 (1日目) で “Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails” というタイトルの発表をしました。 Hypermedia: The Missing Element to Building Adaptable Web APIs in Rai… from Toru Kawamura 時間オーバーしてしまったのが反省点ですが、発表後にまわりの方々から良かったという言葉をいただいて、Twitterなどを見ても好評だったようで、嬉しい限りです。ありがとうございます。 詳しい内容については、るびまに載せる予定なのでそちらに譲るとして、要旨は、“RESTful Web APIs” (O'Reilly) に書かれている内容から、エッセンスを自分なりにまとめたものです
なぜ 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
RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
Webサービスの設計： ハイパーオブジェクトとトリガー - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサービスを設計するための単純明快な方法」の続き、あるいは補足です。 内容： Web APIもWebサイトも同じ トリガーとは トリガーの構造 トリガーについてもっと ハイパーオブジェクトを返すRPC Web APIもWebサイトも同じ 僕の方針は、プログラムが利用するWeb APIであっても、次の原則で設計することです。 API体系は、人がブラウザで閲覧するためのサイトとまったく同じ構造にする。 人間用のサイトを一切作らないときでも同じ原則を適用します。転送オブジェクト（レスポンスのエンティティボディに入るデータ）の形式が(X)HTMLでないときでも同じ原則に従います。 「人間＋ブラウザ」用の転送オブジェクトの形式（フォーマット）といえば、もちろんHTMLです。HTMLの最も重要な特徴はハイパーリンクです。ハイパーリンクがWebを形作っているのです。ですから、HTML以外のフォーマ
HATEOAS - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter9:HATEOAS」のメモ。目次はこちら インターネットが"Web"といわれるのは、一連のハイパーリンクで接続されているから。これによって、「サーフィン」できるし、サーチエンジンは巨大なインデックスを作成できる。 HTMLフォームは、もう一つの特徴。サーバーに情報を登録するには、ページをみて、それを埋めて、送信すればいい。HTMLフォームは自己記述的なやりとりをおこなう形式ということろが興味深い。 リンクとフォーム送信を記述するというアーキテクチャ上の原則は、HATEOASとよばれる。HATEOASとは、Hypermedia As The Engine Of Application
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を混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: RESTFul APIsにおいてHATEOASを使用する利点