IBM DeveloperIBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Foodyn CMS開発日誌 - REST化についての考察（まとめ）
Categories open all | close all Tags 認証 | CSRF | rake | スキンエンジン | フォーム | アクセス制御 | Flash | 名称 | 国際化 | RESTful | モデル | テスト | Aptana | デュアル・コア | OpenID | Subversion | パソコン | タグ | Migration | ドキュメント Search ここではRucleus（仮称）でなぜRESTの設計を取り入れることにしたのか，どういう問題があるのかをまとめておきます。 RESTの意味とそのメリット Rails 2.0の目玉の一つがRESTfulな設計が簡単になったことですが，RESTの機能自体はRails 1.2で導入されています。僕自身は「RESTってWebサービスのインタフェースの1つでSOAPほど面倒くさくないやつでしょ」ってく
RESTはWebAPIの代わりにはならない
Photo by Pulpolux !!! bobchinさんの日記から「やっぱRESTは厳しいのかな？」。 RESTでは、リソースに対して一意のURLに、これって結局データストレージとして使えるっていうだけなんだと思います。MVCでいうmodelの部分。 これは、これでとても大切な部分なのですが、モデルを検索したり、いろいろ機能をRESTで提供するのは、うまくいかないと思います。 Railsだと、create, show, update, destroyメソッドはいいのですが、index(list)メソッドをXMLで返すようにしても、あまりうまくいかないケースが多いと思います。１画面に出る情報が多岐にわたるので、きれいに表現できないんですよね。 １つのコントローラでHTMLとXMLを返す上での最大の問題は、メソッド名の変更が出来なくなることだと思います。APIとして外部に公開してしまうと
ricollab Web Tech Blog » Blog Archive » RESTアーキテクチャスタイル入門の記事をすべて公開しました
1月に三分の一を公開して以来、ずるずると遅れていた残りの記事の公開をやっと行いました。 RESTアーキテクチャスタイル入門 Web アプリケーションのアーキテクチャ Web サービスと REST RESTful な URI の設計 出版は2006年なので2年前の記事です。内容が一部古くなっている部分もあったため、現時点での最新情報に少しだけアップデートしました。
技術者視点のユーザビリティ考 第22回 “使いやすいURI（URL）”の設計 -- ページをリソースとして考える：ITpro
前回，前々回と使いやすいURIの設計のポイントについて見てきました。今回も引き続き，使いやすいURIにするにはどうしたらいいのか，ということについて考えていきます。 URIの使いやすさについては，いろいろと考える話題が多いのですが，ここで話題として取り上げるのは「ページをリソースとして考える」ということについてです。リソースとは，そのまま日本語に訳せば「資源」という意味になります。 リソースという言葉はいろいろなところで使われています。例えば「これだけの仕事をこなすにはチームのリソースが足りません」といったときには，人的資源というか，そのチームが持っている作業可能量のようなものを意味しています。コンピュータのリソースといえば，処理を行うために必要なメモリー量とかCPUパワーとか，もしくはネットワークの帯域などもリソースと呼ばれます。 これらの例を見ると，リソースは「限りある資源」という感じ
yohei-y:weblog: REST 入門(その5) 四つの動詞 -- GET, POST, PUT, DELETE
» REST 入門 目次 前回、URI で特定できるリソースに HTTP の GET という動詞を適用して、 ある時点・条件での状態の表現を転送するのが REST だという説明をしました。 URI (名詞)に適用できる動詞は GET だけではありません。 今回は GET 以外の三つの動詞を紹介します。 前提知識 ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。 はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。 はてなブックマークに登録したひとつのブックマークを考えてみてください。 このひとつのブックマークエントリが、対象のリソースになります。 たとえば REST 入門の目次をブックマークしたとします。 このブックマークの URI は http://b.hatena.ne.jp/atom/edit/175062 で
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
yohei-y:weblog: REST の勝利宣言と良い XML の見分け方
ITpro Challenge 行ってきました。 豪華なメンバーでどの講演もとても面白かったですね。 江島さんの講演は、Web 上でサービスをやるとはどういうことなのかについてとても示唆に富んだ話だったし、 鵜飼さんのハッカーのソフト工学の話は職場的にすげータイムリーだったし、 なおやさんの話は同時代を生きてきた、生きている者としてとても共感できる内容だったし、 戀塚さんはこれぞハッカーという感じのすごい人でした。 僕は LT の最後に話をさせてもらったわけですが、 ネタを二つ持っていって聴衆のみなさんに選んでもらうことにしました。 結果は REST が勝ったので、当初の予告どおり REST の話をすることに。 結局お蔵入りになった XML の話ですが、もったいなかったので懇親会でお話させてもらいました。 プレゼン中で引用した Web ページはこちらです。 檜山さんの記事 XML ボキャブ
第17回 Web APIにおける使いやすさを考える
これまで本連載では，実際に利用者がアクセスするWebページに直結する，使い勝手について考えてきたわけですが，今回はちょっと視点を変えて，Web APIの使い勝手について考えてみたいと思います。 まずは前提となる定義から。Web APIは，WebサービスAPIとか，Webサービスとか，時には単にAPIと呼ばれたりしています。簡単に定義すればHTTPを利用してデータをやり取りすることで，外部サイトに対してデータを配布したり，複雑な計算や処理などのサービスを提供するものです。もう少し平たく言うと，プログラム内に通常記述する関数（やメソッド）を外部に切り出して，ネットワークを介して呼び出せるようにしたものです。 APIというと，なにもWeb上のサービスに限ったものではなくて，あるライブラリやプログラムの内部の関数やデータに，外部からアクセスできるインタフェース全般を指します。例えば，Windows
RESTful Web Services
a book by Leonard Richardson and Sam Ruby Deprecation notice: RESTful Web Services has been replaced by a new book, 2013's RESTful Web APIs. You can download the original RESTful Web Services in PDF, EPUB, MOBI or DAISY format. You can also read an HTML version online. The work RESTful Web Services is now licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Ev
ぶろぐ。@4bit.net: DHH loves REST!? その1（RESTプラグインの紹介）
« 第5回全日本スヌーカー選手権 | メイン | DHH loves REST!? その2（ActiveResource） » 2006年06月15日 (木) DHH loves REST!? その1（RESTプラグインの紹介） [テクニカル] 日本Rubyカンファレンス2006。DHHのセッション内容がヤバイ。チケットが入手できなかったので聞けなかったけど（発表資料くれー）。タイトルが「One controller, many ins, many outs」→「Discovering a world of Resources on Rails」。うひょー。世界リソース発見。 Blogなどでレポートを書いてるみなさんありがとうございます。以下関係部分を引用。 moroの日記 - 日本Rubyカンファレンス2006 二日目より CRUD素晴らしい HTTPのメソッドで、既にCRUDできるじゃ
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
yohei-y:weblog: REST 入門(補足2) POST と PUT
» REST 入門 目次 kwatch さんから以下のようなコメントをもらいました。 POSTとPUTの説明が逆では？たしかPUTが新規作成であり、POSTは送ったリソースの処理を指定したURIに任せるということだったと思いますが。 コメント欄では返答が書ききれなかったので、補足として新しいポストを追加します。 RFC2616 では PUT の動作が二つ規定されています。 指定した URI がすでに存在している場合 PUT はその URI のリソースを修正(更新)する 指定した URI が存在しない場合 PUT はその URI のリソースを新規作成する PUT を規定している 9.6 節には POST と PUT の違いとして以下の記述があります。 The fundamental difference between the POST and PUT requests is reflect
yohei-y:weblog: REST 入門
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
Ajax と REST | | プログラマ2.0日報 | あすなろBLOG
最近、レガシーな Web アプリ開発でも、Ajax を機能として取り入れよう...というのが、かなり具体的な案件として出るようになっています。本流の遷移は通常の POST メソッドによるレガシーな遷移で行うが、たとえば、「一覧表のソート順変更」「検索条件の変更」といった処理は、ＵＩとしては重要ですが、処理の流れとしては副次的なものとなります。そういう副次的処理を Ajax 部品に任せてしまう、としたら、流れが理解しやすく、メンテも楽なコードになることでしょう。 この時、重要なポイントがあるように思います。それが実は、REST と同じ結論になるので面白いと思うので書きましょう。「REST って何？」という方もいるでしょうが、これ最近かなり流行ってる Webアーキテクチャ・スタイルです。「REST ＝ SOAP や XML-RPC ではない簡単な Web サービス」というお考えの方もいるかも
Representational State Transfer - Wikipedia
この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2023年11月） Representational State Transfer (REST、レスト[1][2][3][4]) は、ウェブAPI（ウェブアプリケーションプログラミングインタフェース）の定義に使用されるアーキテクチャスタイル（共通仕様）[5]であり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるロイ・フィールディング（英語版）がウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。 RESTは、初めはアーキテクチャの原則と制約の集まり（後述）を指してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTful Worldでの素晴らしいURI