perl-mongers.orgThis domain may be for sale!
The Amazing Blog : Your Web Service Might Not Be RESTful If…
Rando’s Random RamblingsThe other day, I gave a brief talk about our HTTP Library, Resourceful. After a few minutes of going over the features, it became apparent to me that very few people have taken the time to appreciate the finer points of HTTP. Everyone who calls themself a web application developer needs to take a few hours to read RFC2616: Hypertext Transfer Protocol — HTTP/1.1. Its not ve
Discover Subject Matter Experts – Feedly Blog
Feedly product updates, case studies, and resources to help you use AI to collect, analyze, and share intelligence. Start your free trial.
RESTクライアントが知っているべきこと - 岩本隆史の日記帳（アーカイブ）
クライアントとサーバの密結合を避けられるのが、RESTスタイルに従って得られるメリットのひとつです。クライアントが、アプリケーションの挙動に関する知識をほとんど持たなくてよいわけです。 とはいっても、まったく何も知らないではクライアントたりえません。では、何を知っていればよいのでしょうか。 知っているべき4点 その答えは、Roy T. Fielding による記事「REST APIs must be hypertext-driven」で、すでに示されています。下記の4つです。 通信プロトコル（communication protocol） 初期URI（initial URI） メディアタイプ（media types） リンク関係（link relations） AtomPubを例にとると分かりやすいでしょう。 通信プロトコル＝HTTP 初期URI＝サービス文書のURI メディアタイプ＝「a
InfoQ: RESTfulなアプリケーションを記述する
しかしながら、上述のRoy Fieldingの言葉を言い換えると、このようなアプローチはRESTの基本的な原則の一部と相反します。たとえ私たちがこの異議を無視するとしても、 HTTP上に分散型アプリケーションをRESTfullに構築しようとしている人たちには、根本的な問題が残ります。契約を形式的に定義することなくサーバーからの取得はどうするのでしょうか？契約なしでクライアントとサーバーが正しく実装しているということをどのように確かめるのか、それぞれの設計仕様書だけでなく、その他、適切なビジネス/技術ポリシーはどうするのでしょうか？ アプリケーションプロトコルとしてHTTPを使用し、RESTfullな構築をしている分散型アプリケーションには、同じような性質と種類の契約があります。私たちは、何を探し、どこを探すかを知る必要があります。同じ方向にしたがい、私たちが記述言語に向かうならば、それはW
WADLは必要か・その1 - 岩本隆史の日記帳（アーカイブ）
識者の間でも結論は出ていない RESTfulなWebサービスのための仕様記述言語・WADL（Web Application Description Language）の必要性については、識者の間でも意見が分かれています。Leonard Richardson（『RESTful Webサービス』の著者の一人）は必要派（「It's Just A Hypermedia Format」）、Joe Gregorio（AtomPubの仕様策定者の一人）は不要派（「Do we need WADL?」）といった具合です。 必要派と不要派の間には、Tim Bray（IETFのAtomPubワーキンググループに参加）のような消極的賛成派（「On Web Service Definition」）、Sam Ruby（同、また前掲書共著者）のような別解模索派（「Doctrine of Minimum Necessar
REST API - Brightkite API | Google Groups
RESTful API Overview Brightkite provides a RESTful API for integration with 3rd parties. Your application must be authenticated before you can begin making calls to the REST API. Please see the Authentication Guide for instructions on how to do this. This document also assumes that you have a basic understanding of REST and HTTP. Registering and Authorizing API ApplicationsTo register a new app
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
Twitter API Wiki / REST API Documentation
Introduction Twitter exposes some of its functionality via an Application Programming Interface (API). This document is a reference for that functionality, and aims to serve as a reference for developers building tools that talk to Twitter. Table of Contents Concepts Authentication With the exception of the public timeline, all Twitter API methods require authentication. All responses are relativ
続・コマンド的な処理をどうやってRESTfulに実装するか - 岩本隆史の日記帳（アーカイブ）
「コマンド的な処理をどうやってRESTfulに実装するか」に書いた内容を敷衍します。 SunのクラウドサービスAPI 先日、Sun MicrosystemsがSun Cloudというクラウドサービスを提供すると発表しました。 米Sun、Amazon対抗のクラウドサービス「Sun Cloud」を発表 - SourceForge.JP Magazine この記事には、クラウド操作用APIがRESTベースで提供される予定であることも書かれています。 Sunは開発者向けにクラウドAPI「Sun Open Cloud API」を提供する。RESTベースのAPIで、CreativeCommonsライセンスの下でリリースするため、開発者はSun Cloudと相互運用性のあるクラウドを構築できるという。 そのAPI仕様のドラフトが「The APIs for the Sun Cloud: Wiki: Hom
RESTful JSON
DeWitt: @dehora Sorry, that should read: We haven't created an AtomPub *for* RPC yet. IMHO, that's the biggest gap today. What we seem to need is a data-oriented REST protocol. We already have document-oriented REST protocols covered with the Atom Publishing Protocol, but what if the information you want to convey is data, i.e. doesn't have the minimum meta-data to qualify as a document, such as a
IR対策だっていいじゃないか上場企業だもの - 岩本隆史の日記帳（アーカイブ）
それから日本においてあちらこちらのメディアやブログで OpenID を積極的に推奨しているのは、印象として言えば上場企業の技術者に限られていますし、最先端の有望そうな技術を紹介しているように見えて、実は IR 対策でしかないという気がしてしまうのは、残念です。 http://www.architectures.jp/archives/25 仮にそれらの紹介記事がIR対策だったとして何が残念なのか分からないなあ。 上場企業が社員の技術力を投資家にアピールするのは当たり前のことだと思う。記事に間違いがあれば投資家の評価が下がる可能性があるわけだから、覚悟をもって公開するんだろうし。 読者からみれば動機なんかどうでも良くて、重要なのは記事が正しいかどうかじゃないのかなあ。
InfoQ: ErlangとYawsを使ったRESTfulサービス
以前に有名となった「Apache vs Yawsのグラフ」(source)を見て、あなたもまたYawsを使うべきだと思ったでしょうか? 一見すると、そのグラフは、Yawsに対する信じられないくらい大きなスケーラビリティの優位性があるように見えます。Apacheが4000のパラレル接続でダウンしたのに対し、Yawsは80,000を超えるスケール能力を持っています。このグラフに対する反応は大きく二極化する傾向にあります。「これらのグラフは正確な方法で行われたものではなかった」あるいは「Apacheの設定ミスに違いない」というものと、それとは反対に「ワオ！Yawsを利用する価値がある」というものです。 Yawsの比較グラフを信じるかどうかに関係なく、Yaws(サイト・英語)は動的コンテンツを提供するための確かなWebサーバーです。Claes Wikstrom氏は、Yawsを「もう一つのWebサー
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ヒョウタンツギな現代システム事情をRESTでぶっとばせ！ - GoTheDistance
昨日休日出勤して3冊に及ぶKINGJIMを斜め読みしてふと思ったことをTwitterにぼやいた。 ものすごーく高いお金をかけて基幹システムを作っても現場で使っているのはExcelで、そのExcelをベースに手で個別システムに打ち込んで基幹にバッチでつないでいる会社がどれほど多いことか。 http://twitter.com/gothedistance/statuses/721944022 何でこんなことになってしまうかというと、この辺りが大きな原因かな。 基幹システムで管理したい単位と業務で管理したい単位が違う。 基幹システムは情報システム部が、業務アプリは個々の部が勝手に作っている。 1番においては、基幹システムで管理したい単位は仕訳を行うために必要な単位で業務に必要な単位はそれよりもっと細かい商品単価であるとか商品単位であるとか業界標準の何とかコードであったりとかする。特に流通・小売と
FIFO なデータ構造へのアクセスはどうするんだろう - いたわさににほんしゅ
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 から取り出す でいいのかなぁ、
Representational State Transfer (REST)
[Top] [Prev] [Next] CHAPTER 5 Representational State Transfer (REST) This chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, describing the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, while contrasting them to the constraints of other architectural s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTfulなJSON Webサービスのベストプラクティス
REST - InfoQ
http://www.machu.jp/posts/20080101/p01/