Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
Shibu's Diary: cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 By Jeremy Brooks under CC BY-NC 先日、cURL as DSLというツールを公開しました。その後、何度も同じような質問を受けたりしたので、ブログにまとめてみます。 なぜこのツールを作ったの？ RESTfulというものは大分一般的になってきました。HTTPでAPIを提供というのもよく見かけます。ですが、僕はこのRESTfulというやつが嫌いです。 GETのURLをシェアすればいつでも同じページがある(変な状態を持たない)、みたいな思想はいいんですが、HTTPのAPIはどうも使いにくい。ドキュメントのHTTPのサンプルを見て、ドキュメントをじっくり読み込んで、パラメータをJSONやらXMLで組み立ててボディに乗っけて(しかも大抵パラメータがアホのように
[Apiary]Markdownで始めるAPI開発とAPIドキュメント作成 | DevelopersIO
APIを作るとき みなさん、毎日API使ってますか？私は、ワンライナーでAPIをコールすることにハマっています。さて、いつも使っているAPIを作る側になったとき、どのように設計していますでしょうか？また、作ったAPIをどのように使ってもらっていますか？そんな疑問に応えるサービスがApiaryです。 Apiaryとは？ Apiaryは、REST APIをサクッと書けるサービスです。また、APIドキュメントも生成してくれます。モックサーバも提供してくれます。API利用サンプルコードも作ってくれます。うん、使わないって選択肢は無いですねｗ。 無料登録すると早速使えるようになります。チームでプライベートなAPI開発をしたければ有料プランを選択してください。 API開発の流れ API開発の流れは、まずはじめにMarkdown形式でドキュメントを書きます。既にサンプルがあるのでこれを使ってみましょう。
![[Apiary]Markdownで始めるAPI開発とAPIドキュメント作成 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/60d7120d91185f1739fec5fcbd006f066b98e9f6/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F02%2Fapiary-logo.png){kind=logo}
コマンドで確認してみたRESTful#とは勉強会4 | いきあたりばったり
先日第4回目のRESTful#とは勉強会を開催致しました。 今回も時間いっぱい「webを支える技術」読書会をやりました。 前回の反省も踏まえ、休憩を入れましたが、やはり集中が最後まで続いて良かったです。 ところでこの勉強会、初心者向けとはちょっと言いがたくなってきましたね。 しかしながら、出来れば開発始める前に知っておいたほうがいい内容なので、初心者から～と幅広い層向けになってきたと思います。 既に練度が高い方からもこういう意見を頂けて嬉しいです。 HTTPメソッドで冪等性とか考えたことなかったから今日の読書会はすごい勉強になった — Hiroyuki Morita (@chiastolite) 2015, 2月 10 やったこと 今回は「7章 HTTPメソッド」から読み進めました。 最初読むにあたり、川村さんより注意点や問題が出されました(素敵な試み！) RESTful#とは勉強会4 2
技術/HTTP/REST設計思想の "Stateless" との付き合い方 - Glamenv-Septzen.net
id: 1350 所有者: msakamoto-sf 作成日: 2015-02-11 21:34:52 カテゴリ: HTTP プログラミング [ Prev ] [ Next ] [ 技術 ] RESTfulなAPIやWebアプリケーションを開発する際に、一つの疑問が生じる。 RESTでは「ステートレス」を重視して、サーバサイドでのセッション管理ではなく、クライアント側で認証情報や状態を保持して、サーバに都度送る方式を唱えている。これはHTTPで実装するなら、Cookieを使ったセッション管理ではなく、BasicやDigest認証など、HTTP認証を使うことになる。 しかし現実問題として、モダンなWebサイトでBasic/Digest認証を扱うことはなく、サーバサイドのCookieを使ったセッション管理を使うことになる。 RESTにおいて、ステートレスという特性と、現実のセッション管理をどう
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
Rubykaigi2008: REST 信者から見た Ruby と Rails
This document discusses REST and how it relates to Ruby and Rails. Some key points: - REST is an architectural style for building web applications. It focuses on addressability of resources and stateless connections between systems. - Ruby and Rails are well-suited for building RESTful applications due to features like routing and the ability to easily expose resources and links through URIs. - Wh
Web API: The Good Partsを読んだ - AnyType
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 業務ではiOSアプリとバックエンドの開発を両方担当しているので、APIの設計を何回かやってきた。しかし、自分なりのやり方でやってきた部分が多かったので、最近発売されたWeb API: The Good Partsを読んでちゃんとした設計について学ぶことにした。 得られた学びをメモとして残す。 HATEOAS HATEOAS（Hypermedia As The Engine Of Application State）という設計方法を初めて知った。HATEOASではまず、サーバー側はレスポンスに関連するエンドポイントを含め次にアクセスするAPIを簡単に辿れるようにする。クライアント側は最初のエンドポイント以
REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
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
LDAPサーバーに REST API アクセス - Qiita
別名: LDAPサーバーOpenDJを使おう(3) LDAPサーバーOpenDJを使おう(1) の続きの LDAPサーバーOpenDJを使おう(2) の続きです。いよいよ REST API の登場です。 LDAP で問い合わせるの面倒だから HTTP の REST API あったら便利だよねということです。OpenDJ にはそれ自身に組み込まれた HTTP サーバーと、任意の LDAP サーバーをバックエンドとして利用できる REST API Gateway がありますが、今回の紹介は前者です。 権限の問題が解決できずにずっと放置していましたが、もう OpenDJ を使うことはなさそうなので中途半端ですが公開します。なぜ使わないかというと各メジャーバージョンの最初のリリースしか公開されなくなり、Subscription を買わないと更新できなくなったからです。プロダクション環境で使うために
REST Microservices in Go with Gin
10 Jul 2014 comments Tweet Microservices are cool. Simply described, they’re a way to take encapsulation to the next level. This design pattern allows for components of your system to be developed in isolation (even in different languages), keep internal business logic truly internal (no more well intentioned hacks that break encapsulation), and allow for each component to be deployed in isolation
API設計のポイント - ワザノバ | wazanova
Living Socialが7回に渡りSOA (Service-oriented architecture) についてのブログを書いてますが、今回はAPI設計についてのエントリーです。 「APIはRESTful」と言うだけでなく、社内でガイドラインがオーソライズされるように調整すること。設計にあたっての選択肢及び自由度をしっかり考慮すること。そして一番大事なのは、決めた原則とおりにブレなくインプリすること。 どのHTTPステータス（success/error）をどのシチュエーションで採用するか。 204もしくは200をPOSTで使うか？PUTで使うか？ 4xx番台のコードの一貫性。 bodyにエラーメッセージを追加するのか。 認証はどこで？ ヘッダー？もしくはURLパラメータ？ リソースの階層はどうするか。 忠実にRESTfulとするのか、RPCのようなエンドポイント（/inventory
Railsで一度に全部処理するときのRoutes問題
TODO管理をするとして「すべてのタスクを削除したい」とか「すべてのタスクを終了にしたい」っていう要件、普通によくありますね。 これって簡単なくせに「どうあるべきなの？」と迷うことが多くて悩んでいたところ、@tkawaさんがサクッと解決してくれたのでここに残しておきます。 考え方と使われ方 すべてのリソースに対するアクションなのでDELETE /tasksとかPUT /tasksで済ませたいというREST脳が働きますね。 どうやって使いたいか、というと、こんな感じ。 app/views/tasks/index.html.erb 普段はHamlですけど、今回はERBで（手抜き） <h1>Listing Tasks</h1> <table> <thead> <tr> <th>Name</th> <th>Memo</th> <th>Done</th> <th colspan="3"></th>
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
express4でRESTful API作る - yutaponのブログ
ちょっとnode.jsでAPIサーバ作ろうとして express4に上げたらいろいろと使い方が変わっていたので 備忘録的に書いておきます。 expressでのプロジェクトの作り方 ここを見ながらやるのが確実。 https://www.npmjs.org/package/express express3の場合 express3までは $ npm install -g express # グローバルにexpressコマンド入れて $ express appName # expressコマンドでひな形作成 .. $ node app.js # アプリケーション起動 こんな感じでexpressプロジェクトを作れましたが、 express4から結構変更されています。 express4の場合 express4ではひな形を作るコマンドが本体から分離されました。 またアプリケーションの起動方法も変更されて
RESTful Meetup vol.3 を開催しました #RWABookja - ぶろぐ。@はてな
4/12(土)の夜に『RESTful Meetup vol.3』を開催しました。 RESTful Meetup vol.3 - Sendagaya.rb | Doorkeeper 昨年の記事の通り『RESTful Web APIs』の読書会を月2回ペースで開催してきましたが、その後、著者のMike Amundsen(@mamund)さんから、ワークショップのために東京へ行くという知らせがあったので、これはイベントをやるしかない！ということで企画しました。 vol.3ということで、実は過去2回開催しています。そのときは『RailsにおけるRESTfulなURL設計勉強会』というタイトルで、かなりターゲットを絞っていたのですが、今回は「REST」「Web API」というかなり広いテーマにしました。このことでRuby/Railsに限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - Kong/unirest-php: Unirest in PHP: Simplified, lightweight HTTP client library.
GitHub - cookpad/garage: Rails extension for RESTful Hypermedia API
