2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。 一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。 もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRes
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
RESTの時代がやってくるのだ、という記事を1つ前の「時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了」で紹介しましたが、そのRESTも使われ方が進化してきているのだ、ということを、その記事の中でとりあげたProgrammableWebのJohn Musser氏が公開しているの資料の中で解説しています。 3つ紹介しましょう。 バージョン番号の組み込み 最近のREST APIにはバージョン番号がURIに埋め込まれるようになったとのこと。 利用者に状況報告 レイテンシーがどうなっていて、正常稼働しているかどうかといった報告を利用者に対してきめこまかく報告するようになったと。APIに依存した外部サービスが増えたためでしょうね。
ちょっと色々わからなくなったので、誰かのアドバイスを期待してここに書く。 簡単に前提を書くと、UserモデルのCRUDとは別にUserのパスワードを変更する画面が必要になった。Usersコントローラにpassword_editみたいなactionを書くのもあまりきれいじゃないなと思ってコントローラを分けることにした。 resources :users do resource :password end 確実にUserのレコードは必要になるので上記の用にネストさせることにした。ここで気になるのがpasswordのコントローラ名。通常PasswordsControllerになる。ただ、PasswordsController内の処理は確実にUserに依存する処理が入るため、これはこれであまりしっくりこない。別にPasswordsControllerを他で使う予定があるわけじゃないけど、User:
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
この条件での確認画面問題は，トランザクションリソースを導入しなくても，もっとシンプルに考えて解決できると思います． 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ） まず上記の条件から次の事が言えると思います． ユーザ登録処理とはユーザリソースの作成処理と考えられる 画面はあくまでリソース状態が表示されるものなので，画面遷移とはユーザリソースの状態を都度表示しているもの ということで，あくまでユーザリソースとそれに対する CRUD（この場合は DELETE はないが）として考えればいいかな，と． まず最初の登録画面はユーザ作成フォームリソースを取得します． GET /users/new登録画面から確認画面のところはユーザリソースの新規作成と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
