まあそれはすでに通った道なんですぐに対応できたものの、いくらやっても「Not a valid mime-type for relation.」という非常に親切なエラーメッセージ。仕方なくNokiaでLifeblogのPC版を落としてインストールし、ポストして、XML on the wireの解析へ。 で、いろいろ変わった実装をしているもんで、どれがキーポイントなのかまた試行錯誤。Lifeblogが生成するAtom entryを見ると、なんと<content>の中身をいわゆるRFC 2045ばりに、72文字という中途半端な数で改行してやがんの。まさか？と思ってそれに対応してみたけど、やっぱりエラーは変わらず。

After I'd finished with my PHP Atom API implementation, it made sense to try developing a client. Looking at the current discussion of PUT and DELETE versus just using GET and POST there was a general feeling that Javascript and DHTML couldn't support PUT and DELETE. Short history of XmlHttpRequest I'd previously read about something called XmlHttpRequest which allowed Javascript to connect to a s

Code Archive Skip to content Google About Google Privacy Terms

NOTE: This is a work in progress. I haven't finished writing it yet! – Dan Diephouse Overview This tutorial will guide you through the following concepts: How to write a simple Atom Publishing Protocol server using Abdera How to set up an Abdera servlet The DefaultProvider and AbstractEntityCollectionAdapter classes Modelling an employee directory with an Atom Publishing Protocol Service This assu

Code Archive Skip to content Google About Google Privacy Terms

A Short Introduction to the Atom Publishing Protocol 1. Overview 2. Creating and Manipulating Atom Entries 3. Uploading Resources 4. Introspection 1. Overview The Atom Publishing Protocol is a new protocol being developed at the IETF as part of their Atom Publishing Format and Protocol working group that lets you manipulate Atom feeds over a REST-style HTTP interface. The RFC is still in draft sta

2017/03 - Apache Abdera has been retired. For more information, please explore the Attic. An Open Source Atom Implementation The goal of the Apache Abdera project is to build a functionally-complete, high-performance implementation of the IETF Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) specifications. News December 21, 2012: Abdera 1.1.3 Released Abdera 1.1.3 has be

_ AtomPub の multipart 拡張と OpenSocial のバッチ処理 [atompub][opensocial] 以前に "AtomPub で複数リソースをまとめて POST する方法" というエン トリを書きました [2008-03-29-1]．このエントリでは，2通りの "エント リをまとめてPOST する方法" を紹介しました． このうち，"Media Resource と Media Link Entry を同時に POST" が multipart 拡張として正式に標準化されることになりました．元々 Picasa API として使われていた方法で，実績もあるため，標準化はすんな りと進みそうです． また，もうひとつの "複数の Resource をまとめて POST (BATCH 処理)" は，OpenSocial 仕様として正式に採用されるようです．いまのとこ

_ AtomPub - Catalyst::Controller::Atompub v0.5.0 [atompub][catalyst] zigorou さんからアドバイスをもらいつつ，Makefile.PL も直してもらい つつ，コレクション URI の変更方法を修正しました．いままでは，コレク ション URI を変更すると EditURI やサービス文書がおかしくなることが あったのですが，完全に直っていると思います． http://svn.coderepos.org/share/lang/perl/Catalyst-Controller-Atompub/trunk # Atompub の export が多いのは，今さら変更できないということで見逃 # してください ＞＜ 一ヶ月近く前に，daiba さんから "URI がおかしい" という報告をもらっ ていたのですが，わりと面倒な修

_ AtomPub - サービス文書の記述力 [atompub] (2008-06-26 追記) その後の動向を [2008-06-26-1] に書きました． ZIGOROu さんと Catalyst::Controller::Atompub をいじっていて，コレク ション URI をデフォルトから変更したときのあれやこれやを修正したんで すが (CodeRepos にあります)，それについて書く前にサービス文書とその 欠点について簡単にふれておきます． AtomPub サーバを開発していると，コレクションの設計には力を注いでも， サービス文書はおざなりという人が多いのではないでしょうか．サービス 文書はとても影が薄いように思います．ひとつはサービス文書がなくても 動作する状況が多いこと，もうひとつは Atom API 時代には存在しなかっ たことが理由でしょう． サービス文書には，コレク

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