タグ

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

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

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

    RESTのベストプラクティス | POSTD
  • 登録されるとつらいユーザー名リスト - Qiita

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

    登録されるとつらいユーザー名リスト - Qiita
  • 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) に書かれている内容から、エッセンスを自分なりにまとめたものです

    RubyKaigi 2014 で Hypermedia Web API について発表しました - ぶろぐ。@はてな
    mas-higa
    mas-higa 2014/09/24
    ホールBのスケジュールが大幅に遅れてたおかげで聞けた。REST の意味が分かった気がする。良かった。
  • Webサービスの設計: ハイパーオブジェクトとトリガー - 檜山正幸のキマイラ飼育記 (はてなBlog)

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

    Webサービスの設計: ハイパーオブジェクトとトリガー - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • InfoQ: RESTFul APIsにおいてHATEOASを使用する利点

    垂直スケーラビリティと効果的なテストによる金融取引システムのパフォーマンスと効率の最大化 Peter Lawrey氏はJavaチャンピオンであり、Chronicle SoftwareのCEOとして、開発者を鼓舞してソリューションのクラフトマンシップを高めることに情熱を注いでいる。経験豊富なソフトウェアエンジニアとして、Lawrey氏はソフトウェア開発プロセスにおけるシンプルさ、パフォーマンス、創造性、革新性を奨励することに努めている。

    InfoQ: RESTFul APIsにおいてHATEOASを使用する利点
  • HATEOAS - winplusの日記

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

    HATEOAS - winplusの日記
  • 1