Web API Design - 開発者が愛するインターフェイスを作る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が最近リリースされ、重要な変...
最近のRESTの進化。バージョン番号、状況報告、プロダクトとしてのAPI
RESTの時代がやってくるのだ、という記事を1つ前の「時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了」で紹介しましたが、そのRESTも使われ方が進化してきているのだ、ということを、その記事の中でとりあげたProgrammableWebのJohn Musser氏が公開しているの資料の中で解説しています。 3つ紹介しましょう。 バージョン番号の組み込み 最近のREST APIにはバージョン番号がURIに埋め込まれるようになったとのこと。 利用者に状況報告 レイテンシーがどうなっていて、正常稼働しているかどうかといった報告を利用者に対してきめこまかく報告するようになったと。APIに依存した外部サービスが増えたためでしょうね。
時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I（Web Services Interoperability Organization）が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました（参考：WS-I Completes Web Services Interoperability Standards Work（pdf））。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST（Representational State Transfer）と呼ばれるアーキテクチ
確認画面問題とリソースモデリング - 烏賊様
この条件での確認画面問題は，トランザクションリソースを導入しなくても，もっとシンプルに考えて解決できると思います． 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ） まず上記の条件から次の事が言えると思います． ユーザ登録処理とはユーザリソースの作成処理と考えられる 画面はあくまでリソース状態が表示されるものなので，画面遷移とはユーザリソースの状態を都度表示しているもの ということで，あくまでユーザリソースとそれに対する CRUD（この場合は DELETE はないが）として考えればいいかな，と． まず最初の登録画面はユーザ作成フォームリソースを取得します． GET /users/new登録画面から確認画面のところはユーザリソースの新規作成と
確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ）
REST勉強会、参加したかったなあ。知らなかった私が悪いんですが。 勉強会では「確認画面ってどう扱うの？」という議題が出たそうで、私なりに考えていた解をここに提示する次第です。 例示する処理 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 1. トランザクションリソースの作成 クライアントは、登録画面から「トランザクションリソースのファクトリリソース」にユーザ名とパスワードをPOSTします（通信イメージは適当です）。 POST /newaccount-transactions HTTP/1.1 HOST: example.org username=iwamot password=hogehoge 妥当な入力なら、サーバはトランザクションリソースを作成し、そのURLを返します。これが確認画面となります。 HTTP/1.1 201 Crea
続・こんなURI 設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いた「こんなURI 設計、どう？」の続きです。 例：商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ＞ユーザ登録 ユーザ別ブックマークリソース トップ＞iwamotのブックマーク ブックマークリソース トップ＞iwamotのブックマーク＞Webを支える技術 商品リソース トップ＞Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ（例：http://b.hatena.ne.jp/entry/twitter.com/）みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード（ASIN）を用いることにします。
こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
リソース指向フレームワークのBEARが何やらスゴイ予感 - Stellaqua - ＴＯＭの技術日記
これ、密かにスゴイぞ…。 →Google Code Archive - Long-term storage for Google Code Project Hosting. 「こんなWebアプリケーションフレームワークがあったらなぁ…。」と最近ぼんやりと考えていた、そのものズバリな感じで、かなり衝撃を受けています。今まで捕捉できてなかった自分に反省…。orz 今までRails以降の、いわゆるMVCフレームワークに何ともかんともなじめなかったんですが、このBEARに関しては、かなりすんなり考え方が入ってきました。 Rails型のフレームワークになぜしっくりこないのか? せっかくの機会なので、そもそも、なぜRails型のフレームワークが自分的にしっくりこなかったのか、ちょっと考えてみました。 まず、自分のイメージとしてRails型のフレームワークの場合、"URL1つに対してMVCの塊1つが対応
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
InfoQ: REST成熟度モデルの３レベル
原文(投稿日：2010/03/24)へのリンク Martin Fowler氏は、新しい 論文 で、Leonard Richardson氏によって開発された RESTful成熟度の３レベルモデル を使って、 webスタイルのシステムを説明している。 Fowler氏によれば、成熟度モデルの開始点は、リモートなやりとりための純粋な通信システムとして、HTTP を使うことである。この場合、１つのサービスがある－予約サービス、これは１つのメソッドコール（彼の例では、POST）とXML入／出力を使って、特定のリクエストとリプライを交信する。 空いている医者に予約する場合には、リクエストが必要で： POST /appointmentService HTTP/1.1 <openSlotRequest date = "2010-01-04" doctor = "mjones"/> これにリプライを返す： H
ぼくが見ているレール(map.resouces編) - moroの日記
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
リソースが3段以上ネストしたときのmap.resourcesの書き方
RESTfulなサービスを実装するとして、対象リソースがその他のリソースとの従属（親子）関係があるときに、Ruby on Railsではmap.resourcesをネストして記述することが可能になっている。例えば、部署(Division)に所属する社員(Employee)のリソース定義であれば、 map.resources :divisions, :path_prefix => ‘/api’ do |divisions| divisions.resources :employees, :controller => ‘api/employees’ end とすることで、「GET http://localhost:3000/api/divisions/1/employees/2」というURLにApi::EmployeesControllerクラスをマッピングすることができる。この場合、show
Rails2.0のRouting（config/routes.rb）の記述方式についてのまとめ。 » RAILS PRESS
map.connectとmap.purchase 「map.connect」と「map.purchase」はrails1.x系からおなじみですね。 「map.connect」と「map.purchase（任意のパス名）」については、2005年の情報ですが「Routes :: 優しいRailsの育て方 :: ヽ( ・∀・)ノくまくまー)」によくまとめられています。くまくまさんにはいつもおせわになってます。 またパラメータにURLを直接渡したい場合は、「routes.rbでURLを丸ごとパラメータとして渡す記述法 - Hello, world! - s21g」が参考になります。 僕は今のところ利用する機会が無いですが、パラメータを省略可能にしたい場合は「routes.rbで省略可能パラメータを指定する方法 - Hello, world! - s21g」を。 map.with_options 「
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ルーティングの追加 - satake7’s memo
map.resouceで作成されたルーティングで概ねいいんだけど、少しだけ追加したいなということがあります。そういうときのやり方です。 アクションの追加 テーブル全体の一覧を表示する indexアクションとは別に listアクションを追加する場合、「myapp/config/routes.rb」を次のようにします。 ActionController::Routing::Routes.draw do |map| map.resources :items, :collection => [:list] end これでルーティングの一番先頭に listが追加されます。 C:\www\2.5-55.jp> rake routes (in C:/www/2.5-55.jp) list_items /items/list {:controller=>"items", :action=>"list"}
2.0のmap.resourcesのオプション設定いろいろ - ザリガニが見ていた...。
今までおろそかにしていた「ルート設定」ではあるが、Rails2.0からは避けて通ることができない*1と今更ながら思い直し、いろいろ試してみた。以下はその実験結果。 基本 追加オプションなしの基本ルート設定map.resources :slipsによって、以下のルート規則が生成される。 ルート規則は上にあるものが優先される。 .:formatが付属する偶数No.の行は、http://XXXX.XXX/slips.xml等の拡張子付きのリクエストを、respond_toブロックで適切に処理するために存在する。 # ルート設定: config/routes.rb ActionController::Routing::Routes.draw do |map| map.resources :slips end No. 名前付きルート名 メソッド URLパス書式 処理されるコントローラー、アクション
Convivial-Web – WEBを共に愉しむ。
iPhoneアプリ「My Maps Pocket」を昨年の8月にひっそりとリリースしていました。 リリースしてから特に告知もしていなく、いまさらではありますがコチラで紹介させていただきます。 機能はシンプルで、Google MapsのマイマップをiPhoneで見ることができるというものです。 地図表示、リスト表示、詳細情報の表示、標準地図へのリンクなどの機能があります。 現在は、ポイント（アイコン）にのみ対応していますが、ライン、ポリゴンの表示にもいつか対応したいと思います。 他にも、ポイントの追加・編集、自分以外が作成したマイマップの表示、Google以外のMyMap系サービスにも対応したいです。いつになるかはわかりませんが、、、 書籍でも紹介して頂いたようです。 iPhoneでGoogle活用第一弾 – Reader’s Forumより引用: 写真部つながり、新刊つながりというわけでは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ): 山本陽平: 本
http://www.machu.jp/posts/20080104/p01/