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の基本的な発想は、HTTPメソッドでリソースをCRUDできるはずだ、というアイデア。 では、HTTPメソッドは、そもそもどんなものなのか？ 「安全なメソッドと冪等{idempotent} なメソッド」でいくつか語られている。 「RESTful Webサービス」で「べき等」という概念が出てくる。 「べき等」とは、同じ操作を何度行っても同じ結果であること。つまり副作用がなく安全であることを意味する。 少なくとも、GETはべき等に使うならば、安全であると言える。 しかし、GETで、リソースの削除や更新を行う時も、実はよくある。 REST思想に従うならば、GETは副作用を起こしてはいけない。 POST、PUT、DELETEがリソースの更新で副作用を起こすように使うべき。 RailsはREST思想を忠実に反映している。 また、Strutsも「http://～/***.do」というURLを見る
RESTful な HTTP の使いかたという文脈で、特に構造を持たないような集合をリソースとして、CRUD を行うという話はよくある。(cf. http://yohei-y.blogspot.com/2005/04/rest-5-get-post-put-delete.html) では、キュー(FIFO なデータ構造)を扱うにはどのように構成したらよいのか? と考えはじめて分からなくなった。 head には突っ込むことだけが出来る tail からは取り出しだけが出来る その他の要素には(管理とかは置いといて)アクセスできない PUT/DELETE の羃等を知らなかったときには、キュー(queue.hoge という名前だとする)をリソースと見立てて、 PUT /queue.hoge で head に突っ込む DELETE /queue.hoge で tail から取り出す でいいのかなぁ、
yohei-y:weblog: REST 入門(その8) REST でないもの
» REST 入門 目次 WWW は REST アーキテクチャスタイルのアーキテクチャを採用した実装のひとつですが、 REST アーキテクチャスタイルでないアーキテクチャの WWW アプリケーションもかなり存在します。 REST でないものを一言で言ってしまうと、 URI と HTTP を正しく使っていないもの、ということになります。 以下では URI と HTTP の誤った使い方について説明します。 URI をクライアントで組み立てる URI をクライアント側でごちょごちょ組み立てなければならないのなら、それは REST ではありません。 たとえば、はてなブックマーク AtomAPI が、こんなインターフェースだったらどうでしょう? ブックマークをキーワードで検索する。 POST /uso/bookmarkSearchService HTTP/1.1 Host: b.hatena.ne.
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
馬鹿につける薬: 実際に設計してみよう その3
さて、前回で、RESTというスタイルで考えた場合、既存のシステムとは異なるURL体系になることがわかった。 これは何もおかしなことではなく、既存のwebアプリではアプリケーション（というよりもインターフェースか？）が前面に出ており、実際に操作したいリソースはDBという形で見えなくなっており、RESTではそれを覆して、リソースを前面に押し出し、アプリケーション（インターフェース）をプロトコルの中に格納したからだろう。 というわけで、URLについてもう少し考えてみることにする。 まずは先送りにした検索について考えてみようと思う。 会議室予約システムを考えた場合、検索したいのは「空いている会議室」だけだろう。 そこで、空いている会議室を検索する方法（URL）についてのみ考えてみる。 まず、既存のシステムだとどのようになるだろうか？ 多分こんな感じになるんじゃないだろうか？ http://intr
2007年09月09日13:24 by 山崎泰宏 政治的理由で大手ベンダはノータッチ？ カテゴリワークスタイル雑談 Tweet sparklegate Comment(2)Trackback(0) RESTで有名な山本陽平さんの記事よりREST の勝利宣言と良い XML の見分け方政治的理由で大手ベンダはノータッチとあるが、そうでもない。 RECRUIT + Sun microsystems - Mash up Award複雑化するWebシステムの連携を最適化する「システム連携導入支援サービス」を開始この他にも結構あるのだろうと思うけど、ひとまずブックマークしてあったところから取り急ぎ。 結局、B2B分野でシステム開発を行っているだけであれば、RESTなんてキーワードはお客様からも出てこないし、ウチはRESTでバリバリでっせと布教したところで「うーん、何でもいいんだけど、ちゃんと動くの？」
Posted by: Hirotaka Ogawa @ April 26, 2006 06:01 PM | 暇を見つけてGoogle Data APIs Protocolをしげしげと読んでみていた。よくできているね。 Google Data APIs Protocol ところで話はかわって、識者の人々が「RESTは難しい」「RESTを説明するのは難しい」と繰り返し発言している。事情に詳しくない(しかし興味は持っている)市井の人々に「そうなんだー、難しいんだー」という気分が蔓延するのは、REST推進派の人々にはネガティブに作用するはずで、なんでそんな発言をするのだろうと思う。私自身は門外漢なこともあって「難しい」理由がいまいちよく分からない。なんも難しくないと思えるけれど。 で、冒頭の話に戻るわけで、もしそんなに「RESTが難しい」のなら、もう「Google Data」互換APIを実現するフ
2006年04月22日20:50 カテゴリWEB+DB PRESSiTech RESTは簡単なんだけど... というわけで早速質問です。 WEB+DB PRESS yohei-y:weblog: WEB+DB PRESS Vol.32 に REST の記事を書きましたただ、やっぱり REST は難しいですね。人に説明するたびに思います。記事でわからないことがあれば、ここにコメントしていただければできる範囲で返答しようと思います。なぜAtomPPでは、記事の新規作成がPOSTで、更新がPUTなのでしょう。 WebDAVやFTPといったファイル操作系のProtocolでは、PUTはコンテントをアップロードするためのコマンドです。それとの整合性を考えたら、コンテントの新規作成をPUTでやって悪いわけというのが思いつきません。 あるいは、URIの名前を、Clientの意向で決める場合(例えばアップ
ソフトウェア開発のお仕事メモや、フェイキックIOLの手術体験談をマイペースに残していました。 もうあの頃へは戻れない・・・ 日常、XML WEBサービス（SOAP WSDL）を開発していると、 なるべくWEBメソッドを呼びたくない、というご意見をよく頂きます。 トラフィック量の問題もあるし、そもそもパフォーマンスが悪くなるから WEBメソッドは呼びたくないわけです。 でも、私は開発してていつも感じていたんですが 言うほど重いだろうか・・・ ずっと気になっていたので、調べてみました。 本当はサンプルプログラムでざっと試すつもりだったんですけど、 ちょっとググったらいきなり結論が出てきました。 [XML Webサービスに待ち構える暗黒面（前編）] http://www.atmarkit.co.jp/fdotnet/vbcheer/vbcheer05/vbcheer05.html 上記ページに、
はてな 人力詮索サイト さては http://sensaku.hatena.ne.jp/ ライブドア http://www.livedoor.com/ ↑常にエイプリルフール企画を本気で実行するようなこの会社にしては地味。 sa.notwork.jp（←どこ？） JPRSのIDN実装上の日本語文字集合類似字形の問題 http://sa.notwork.jp/2005/NOTWORK.JP-SA:050401-00.html このページの下のほうに各社企画へのリンクがあります。 http://www.i-mezzo.net/log/2005/04/01.html はてながいままでいろんなページで公開していたサービスが１つのページにまとまりました。 http://www.hatena.ne.jp/info/webservices 個人的に注目なのが、RSSフィードを堂々と「ウェブサービス」と称
http://www.markbaker.ca/2005/11/ServiceOrientedWeb/ 第八回XML開発者の日のMark Bakerのプレゼンテーション資料。RESTifarianのMarkらしい内容。どこかに、REST vs. MESTのまとまった比較資料はないのだろうか? XML開発者の日は行きたかったんだけど、気がついた時はすでに応募者多数で締め切り。Binary 2.0もそうだったし、最近、チェックがあまいのか。 追記: 他のプレゼンテーションマテリアルもhttp://www.asahi-net.or.jp/~eb2m-mrt/kaihatsu8.html から入手できる。
最近RSS関連の有益な情報をたくさん配信してくださっているRSSマーケティングガイドさんに、面白い記事が上がっていました。 HTMLバージョンが無いRSSで配信されるだけのブログってありでしょうか？あるブロガーの一言が少しだけ話題になっているようです。 ということで、特定の情報を特定のユーザーだけに配信したい、という目的であればRSSだけのブログでいいんじゃないかというお話です。RSSによる全文配信が普通になりつつある昨今、自分のサイトのリピーターと思われるユーザーはそのほとんどがフィードリーダーで情報を読み、そこで完結しているのだからHTMLバージョンいらないじゃないと。HTMLに来るユーザーは検索エンジン経由のユーザーで(一見さんだから)そこでは有益なコミュニケーションが難しいなどなど。 そういえば以前にもギークな人たちの間でそんな話題になったことがあったなあなんて思いながら読んでいま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
