タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

RESTに関するhondamsのブックマーク (13)

  • RESTful勉強会 - RESTful読書会

    RESTful勉強会 Wiki † このコミュニティーではWebサービス/Webアプリケーションを作るためのいろいろなノウハウを議論していきたいと思っています。 この勉強会は当初「RESTful Webサービス」(Leonard Richardson, Sam Ruby 著、山 陽平 監訳、株式会社クイープ 訳)を読んで議論をしていました。 今後は平日夕方開催で行っていきます。毎回いくつかのテーマを作ってそれを普段から実践/調査されている方をお招きしてお話いただいて、そこから議論をするという形をとっていければと思っています。 主な活動場所は次のものになります。 イベント告知および日々の議論 googleグループ 個人的に意見等を表明するための場所 はてなグループ ここ見たら?という場所を残していく場所 参考文献等 現在「第6回勉強会」の参加受付を行っております。是非ご参加下さい。 ↑

  • ROA は「究極のオブジェクト指向」?(RESTful本読書会) - 木曜不足

    5/10 の「RESTful Web Services」の第2回読書会に参加します。 実はキャンセル待ちキューでぶすぶすくすぶっていたところ、1週間前になっても5章を読む担当がまだ決まってないと聞き、「やりますやります」と kunit さんに名乗り出て参加を勝ち取るという裏技を使ったとかなんだとか。 というわけで今せっせと5章を読み込んでいるところ。 最初、5章のタイトル「読み取り専用のリソース指向サービス」を見て、「つまり GET 限定の REST かあ……それなんて Web?(終了)」とか思ってしまったのだが(そして根的には実際その通り)、細部になかなか味のある記述があるおもしろい章だったりする。 読書会で担当してなかったら斜め読みして終わってたろうから、なかなかいい機会を得たなあ。 せっかくなので、機運というか自分の気分を盛り上げるために5章を読み解いた内容を一部先出ししてみよう。

    ROA は「究極のオブジェクト指向」?(RESTful本読書会) - 木曜不足
  • REST入門

    第2版(2008年1月19日):翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。稿では、筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に

    REST入門
  • yohei-y:weblog: REST 入門

    語の REST のリソース集を以前作ったのだが、 日語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は

  • Microsoft Learn: Build skills that open doors in your career

    Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find

    Microsoft Learn: Build skills that open doors in your career
  • http://www.projectzero.org/wiki/bin/view/Documentation/CoreDevelopersGuideREST

  • IBM Developer

    IBM 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.

    IBM Developer
  • Representational State Transfer - Wikipedia

    この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。(2023年11月) Representational State Transfer (REST、レスト[1][2][3][4]) は、ウェブAPI(ウェブアプリケーションプログラミングインタフェース)の定義に使用されるアーキテクチャスタイル(共通仕様)[5]であり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるロイ・フィールディング(英語版)がウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。 RESTは、初めはアーキテクチャの原則と制約の集まり(後述)を指してい

  • 連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説(前編)

    IBM 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.

    連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説(前編)
  • RESTアンチパターン

    多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では

    RESTアンチパターン
  • 技術者視点のユーザビリティ考 第22回 “使いやすいURI(URL)”の設計 -- ページをリソースとして考える:ITpro

    前回,前々回と使いやすいURIの設計のポイントについて見てきました。今回も引き続き,使いやすいURIにするにはどうしたらいいのか,ということについて考えていきます。 URIの使いやすさについては,いろいろと考える話題が多いのですが,ここで話題として取り上げるのは「ページをリソースとして考える」ということについてです。リソースとは,そのまま日語に訳せば「資源」という意味になります。 リソースという言葉はいろいろなところで使われています。例えば「これだけの仕事をこなすにはチームのリソースが足りません」といったときには,人的資源というか,そのチームが持っている作業可能量のようなものを意味しています。コンピュータのリソースといえば,処理を行うために必要なメモリー量とかCPUパワーとか,もしくはネットワークの帯域などもリソースと呼ばれます。 これらの例を見ると,リソースは「限りある資源」という感じ

    技術者視点のユーザビリティ考 第22回 “使いやすいURI(URL)”の設計 -- ページをリソースとして考える:ITpro
  • クールなURIは変わらない -- Style Guide for Online Hypertext

    クールなURIとは? クールなURIとは変わらないもののこと。 どんなURIが変わってしまう? URIは変わらない:人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき(もしくはドキュメントのメンテナンスをやめてしまう)理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう

  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • 1