タグ

restに関するkicchomu3のブックマーク (6)

  • Catalyst::Controller::Resources でオーバーロード POST を使いたい - 日向夏特殊応援部隊

    と id:ikasam_a にわがまま言ったら Catalyst::Request::REST::ForBrowsers ってのを教えて貰ったよ。 オーバーロード POST って何だよって方は、 統一インターフェイスと PUT and DELETE tunneled POST パターン - masaki@catalyst - Catalystグループ ROA と Catalyst - masaki@catalyst - Catalystグループ とか読むと幸せになれると思います。 使い方 MyApp にて、こんな感じにしときます。 package MyApp; use strict; use warnings; use Catalyst::Runtime '5.70'; use Catalyst::Request::REST::ForBrowsers; ### 中略 __PACKAGE__

    Catalyst::Controller::Resources でオーバーロード POST を使いたい - 日向夏特殊応援部隊
  • ricollab Web Tech Blog » Blog Archive » RESTアーキテクチャスタイル入門の記事をすべて公開しました

    1月に三分の一を公開して以来、ずるずると遅れていた残りの記事の公開をやっと行いました。 RESTアーキテクチャスタイル入門 Web アプリケーションのアーキテクチャ Web サービスと REST RESTful な URI の設計 出版は2006年なので2年前の記事です。内容が一部古くなっている部分もあったため、現時点での最新情報に少しだけアップデートしました。

  • ricollab Web Tech Blog » Blog Archive » RESTとリソース指向アーキテクチャについての資料

    2/12 に NTT コミュニケーションズ様の社内勉強会にて、REST に関する講演をさせていただきました。NTTコミュニケーションズ様の了解をいただいたので、その資料を公開します。 REST を具現化するアーキテクチャとして、「RESTful Web サービス」で提案されているリソース指向アーキテクチャ(Resource Oriented Architecture; ROA) をご紹介しました。 TrackBack URI “RESTとリソース指向アーキテクチャについての資料” に対するコメント(1) Slashcolon /: さん: 2008-02-15 0:07:11 RESTとROAの基をお勉強… まぁ、REST の基は押さえておきたいと言うか、押さえておかないとWeb 2.0が語れないらしい NTT コミュニケーションズの社内勉強会での講演資料… 『RESTとリソー

  • REST入門

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

    REST入門
  • 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
  • naoyaのはてなダイアリー - REST と GET

    RESTful なアプリケーションでは、対象とするリソースに副作用を及ぼすときは POST なり PUT を使うのがベストプラクティス。(ベストプラクティスという言葉を使ってみたかった!) この考え方はウェブアプリケーションを作るときに、GET にするか POST にするかに明確な指針を与えてくれてすっきりします。 で、ふと思ったんだけど、表面的には GET でよさそうだけども実は中でリソースに副作用が及んでいるような代物はどうしたらいいんだろうなということ。例えば検索エンジンなんかで、クリックに合わせて後ろでクリック回数を数えてたり統計とってたりするものがあると思うんだけど、そういう類。 ウェブサイトの検索エンジンとかだとクリック対象の URI が差すリソースが外部サイトでちょっとイメージしづらいので、例えば search.cpan.org など。モジュールの検索結果からのクリック回数を

    naoyaのはてなダイアリー - REST と GET
  • 1