[B! rest] mas-higaのブックマーク

RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ

※この投稿は米国時間 2022 年12月1日に、Google Cloud blogに投稿されたものの抄訳です。オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便

mas-higa 2022/12/19

リンク

ツイッタ―のリツイート機能を使ったプレゼント企画って当たりあるの？

最近ツイッタ―をしていると、﹁リツイートしてくれると、抽選でプレゼント！﹂チラホラ見かけますよね。でも、私としては自分が本当に抽選されているか、ちょっと懐疑的なんですよ。その理由を記事にまとめてみました。追記:当初﹁無理そう﹂と結論づけていましたが、﹁できそう﹂です。当初誤った結論を投稿していまい、申し訳ありません。また、id:kw5様とid:tockthey様にはご指摘いただきありがとうございます。 Twitterでリツイートするだけでプレゼント抽選とは見たことがある人ならわかるとおもいますが、ツイッタ―のタイムラインでこんなツイートを見かけるときがあります。﹁プレイステーション4﹂30台プレゼントします！応募方法はこのツイートをリツイートのみ！当選連絡はDMで行うのでフォローだけお願いします。 ⬇︎因みにユーチューブでは100台プレゼントしてます⬇︎https://

mas-higa 2017/08/19

O'Reilly の T シャツ当たったことあるよ…って、そういう話じゃなかった。

リンク

RESTのベストプラクティス | POSTD

現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR

mas-higa 2015/01/07

リンク

登録されるとつらいユーザー名リスト - Qiita

Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatena blog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc

mas-higa 2014/12/25

リンク

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

mas-higa 2014/11/19

リンク

RubyKaigi 2014 で Hypermedia Web API について発表しました - ぶろぐ。@はてな

9月18日の RubyKaigi 2014 (1日目) で “Hypermedia: the Missing Element to Building Adapta ble Web APIs in Rails” というタイトルの発表をしました。 Hypermedia: The Missing Element to Building Adapta ble Web APIs in Rai… from Toru Kawamura 時間オーバーしてしまったのが反省点ですが、発表後にまわりの方々から良かったという言葉をいただいて、Twitterなどを見ても好評だったようで、嬉しい限りです。ありがとうございます。詳しい内容については、るびまに載せる予定なのでそちらに譲るとして、要旨は、“RESTful Web APIs” (O'Reilly) に書かれている内容から、エッセンスを自分なりにまとめたものです

mas-higa 2014/09/24

ホールBのスケジュールが大幅に遅れてたおかげで聞けた。REST の意味が分かった気がする。良かった。 ●rubykaigi2014 ●rest ●web ●api

リンク

なぜ 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

mas-higa 2014/03/30

リンク

RailsにおけるRESTfulなURL設計勉強会メモ #sendagayarb - 130単位

zusaar.com -&nbspzusaarリソースおよび情報参加してきました。以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良いJSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながるリソースモデリングパターンの提案 (@tkawa)

mas-higa 2012/07/24

リンク

Webサービスの設計：ハイパーオブジェクトとトリガー - 檜山正幸のキマイラ飼育記 (はてなBlog)

﹁Webサービスを設計するための単純明快な方法﹂の続き、あるいは補足です。内容‥ Web APIもWebサイトも同じトリガーとはトリガーの構造トリガーについてもっとハイパーオブジェクトを返すRPC Web APIもWebサイトも同じ僕の方針は、プログラムが利用するWeb APIであっても、次の原則で設計することです。 API体系は、人がブラウザで閲覧するためのサイトとまったく同じ構造にする。人間用のサイトを一切作らないときでも同じ原則を適用します。転送オブジェクト︵レスポンスのエンティティボディに入るデータ︶の形式が(X)HTMLでないときでも同じ原則に従います。﹁人間＋ブラウザ﹂用の転送オブジェクトの形式︵フォーマット︶といえば、もちろんHTMLです。HTMLの最も重要な特徴はハイパーリンクです。ハイパーリンクがWebを形作っているのです。ですから、HTML以外のフォーマ

mas-higa 2012/02/02

リンク

InfoQ: RESTFul APIsにおいてHATEOASを使用する利点

Spring BootによるAPIバックエンド構築実践ガイド第2版何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

mas-higa 2012/02/02

リンク

HATEOAS - winplusの日記

※オライリーから翻訳書﹃JavaによるRESTfulシステム構築﹄が出ましたので、そちらを参照してください。以下の記事はアテになりません。以下﹃RESTful Javawith JAX-RS﹄﹁Capter9:HATEOAS﹂のメモ。目次はこちらインターネットが"Web"といわれるのは、一連のハイパーリンクで接続されているから。これによって、﹁サーフィン﹂できるし、サーチエンジンは巨大なインデックスを作成できる。 HTMLフォームは、もう一つの特徴。サーバーに情報を登録するには、ページをみて、それを埋めて、送信すればいい。HTMLフォームは自己記述的なやりとりをおこなう形式ということろが興味深い。リンクとフォーム送信を記述するというアーキテクチャ上の原則は、HATEOASとよばれる。HATEOASとは、Hypermedia As The Engine Of Application

mas-higa 2012/02/02

リンク

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を混同しているとりわけ後者は僕を困らせたが、あるチームをコーチすると

mas-higa 2012/01/11

リンク

はてなブックマーク

タグ

関連タグで絞り込む (20)

restに関するmas-higaのブックマーク (12)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス