タグ

RESTに関するHHRのブックマーク (9)

  • HTTP API の設計方向

    Twitter の TL に Dropbox が API v2 で REST をやめたという内容がかかれている記事が流れてきた。

    HHR
    HHR 2016/10/08
  • https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

    https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md
  • モックサーバStubby4jの性能 - 理系学生日記

    モックサーバに Stubby4j というのがある。 一緒に働いている方に紹介してもらったんだけど、これすごく使いやすい。 使い方は README にわかりやすく書いてあるからそれを読んでもらえばよい。 この Stubby4J、性能テストにも使いたいことがあるから、どの程度パフォーマンスがでるか試してみた。 結論としては以下のとおり。横軸が concurrency で縦軸が 1 秒あたりに捌けるリクエスト数になる。 裏でブラウジングしながら測定するなど、かなり適当な計測したけど、600 リクエストくらいは余裕で捌けそう、ということが分かった。 環境 だいたい以下のような環境で測定。GitHub - kiririmode/stubby4j-performance に一連のスクリプト置いてる。 MacBook Pro Mid 2012 2.3 GHz Intel Core i7 16 GB 16

    モックサーバStubby4jの性能 - 理系学生日記
    HHR
    HHR 2016/05/25
    スタブstub、モックmock
  • 「WebAPI 設計のベストプラクティス」に対する所感 - Qiita

    「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図

    「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
    HHR
    HHR 2016/03/29
    結局「複数のリソースを横断的に検索するようなアクション」はどうすれば…
  • 翻訳: WebAPI 設計のベストプラクティス - Qiita

    これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

    翻訳: WebAPI 設計のベストプラクティス - Qiita
  • RESTfulとは

    昔、社内勉強会でRESTについて発表した時に作った資料です。PCのファイル整理してたら発掘されたので、内容をちょっと修正してアップしました。 『Webを支える技術 - HTTP、URI、HTML、そしてREST』 をベースにしたお話です。

    RESTfulとは
    HHR
    HHR 2015/05/12
  • RESTful #とは RailsスタイルからRESTを学ぼう

    Hypermedia: The Missing Element to Building Adaptable Web APIs in RailsToru Kawamura

    RESTful #とは RailsスタイルからRESTを学ぼう
    HHR
    HHR 2014/11/04
    POST→create,PUT→updateでFAっぽい
  • HTMLでWeb APIをつくる - Qiita

    シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか? ビューに書いた方が自然ではないでしょうか? これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用

    HTMLでWeb APIをつくる - Qiita
    HHR
    HHR 2014/08/05
    microdata→JSON変換
  • REST における PUT メソッドと POST メソッドの違い - 星一の日記

    最近 REST に関するを読んでいます。統一された少ないルールで、さまざまな Web アプリケーションを表現できるというのは、妄想が膨らんでワクワクしますね。学んだことをメモがてらに書きます。 RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る PUT も POST も似た役割をもつメソッドです。両方ともリソースの新規作成または更新を行います。この二つのメソッドは何が異なり、どのように使い分けるべきなのでしょうか。 リソースの新規作成 まずリソースの新規作成について。 PUT は URI が指し示すリソースを直接作成することを、サーバーに要求します。たと

    REST における PUT メソッドと POST メソッドの違い - 星一の日記
    HHR
    HHR 2014/02/08
    新規作成と更新でput&postで求められることの説明
  • 1