abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Abley" <james.ab...@gmail.com>
Subject Abdera with JCR
Date Mon, 28 Jul 2008 19:29:42 GMT
Hi,

I'm finally getting the chance to try out AtomPub in anger.

We have a CMS that is backed by JCR. We need to expose a remote API to
that CMS, and AtomPub seems like a reasonable first choice.

Our initial requirement is to be able to create new media entries, and
update entries to reference the new media entries.

I've spent the day reading the docs and code and trying out a few
ideas and now I have a few questions.

Our first iteration needs to support something like the functionality
below. Please feel free to point out where I'm going wrong.

I'm using Abdera trunk - from JIRA commits, this looks to be where
development is happening, rather than in a branch?

I'm envisaging the URIs to be something like this:

1. https://example.com/atom/

GET :  will return the Service document. Basic auth will be used to
identify the client and the Service document representation will vary
depending on the authorization allowed to each account; i.e which
workspaces they have access to. For my application, there is a 1-to-1
correlation between AtomPub workspaces and JCR workspaces. I have this
serving a Service document currently, albeit within implementing any
of the security requirements.

2. https://example.com/atom/{workspace}/{collection}/

GET - will return the collection feed, which will probably be pagable
via http://tools.ietf.org/html/rfc5005 . We might also require
OpenSearch at a later date.

POST - will create new items in the collection. We will allow creation
of Media resource and Entry resources. To control the path of an item
within JCR, we're thinking of using the Slug header and defining the
semantics of that Header within our server to mean an absolute path
within JCR, or a Node UUID within JCR.

Is that bad?

3. https://example.com/atom/{workspace}/{collection}/{id}

GET - will retrieve an Entry.
PUT - will update an Entry.
DELETE - will remove an Entry, blah.

I think I have a reasonable high level understanding of AtomPub; I've
also read Sam Ruby and Leonard Richardson's book. I did consider
rolling our own RESTful API, but I was hoping AtomPub would be more
standardised and thus hopefully less work for other clients to work
with.

Initial use case - create new binary items
----------------------------------------------------

As an example of what I'm trying to do, we have different types of
content in the CMS (which I'll probably expose at least a collection
for each type of content). One of these types might be images. Since
our application works on mobile and has to cater for a wide variety of
user-agent capabilities, we define the image content type to be
capable of having zero or many image files associated with it, so we
have an instance of an image content type (say, a picture of an
Atom-Powered Robot) that has many different representations of the
same resource (a 120*80 JPG, 120*80 PNG, 150*100 GIF, etc). We have
another system that spits out these different representations give a
single master image. This system would like to be able to update the
CMS by uploading the new representations as they become available.

So initially, the Entry for the Atom-Powered Robot image might look like this:

<entry xmlns="http://www.w3.org/2005/Atom">
      <title>Atom-Powered Robots Run Amok</title>
      <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
      <updated>2003-12-13T18:30:02Z</updated>
      <author><name>John Doe</name></author>
      <content>Some text.</content>
      <link rel="edit-media"
href="https://example.com/atom/workspace/images/atom-powered-robot.jpg"
/>
    <link rel="edit"
href="https://example.com/atom/workspace/images/atom-powered-robot-id"
/>
      <a:properties xmlns:a="http://example.com/xmlns/2008/07/pub">
          <media:group xmlns:media="http://search.yahoo.com/mrss/">
                <media:content
               url="https://example.com/atom/workspace/images/atom-powered-robot.jpg"
               fileSize="12216"
               type="image/jpeg"
               height="200"
               width="300"  />
          </media:group>
     </a:properties>
    </entry>

So my understanding of AtomPub means that I need to POST the binary
(say, a PNG version) to the collection to create a new Media Resource
and Media Link Entry. Is it wrong of me to define a side-effect of
that operation to mean also altering the Atom-Powered-Robot image
Entry to have a new <link rel="edit" /> and <link rel="edit-media" />,
or should I require an explicit GET and PUT on that Entry to cause
that update to happen?

Should I maybe expose a collection for each content item that can
contain such a collection of different representations? I thought
about that, but some of them can contain multiple collections, so
where's the cut-off point with that approach?

API questions
========

As I mentioned above, I have to the Service document working to some
degree. I'm a little uncomfortable about the classes in the imp
package that I've used to get that working though. What's the
preferred way to feedback potential points where maybe the API should
be altered to make it obvious what to extend and what is not
considered published?

URI mapping - I don't know Rails; I know Django, so the RouteManager
looks intriguing. I'm currently using the RegexTargetResolver for the
URIs that I've outlined about, but is there a better way for me to be
managing that aspect of my implementation?

Sorry it's such an essay!

Cheers,

James

Mime
View raw message