[geeklog-devel] Webservices API (was: Student wakeup call)
Dirk Haun
dirk at haun-online.de
Thu Nov 1 13:11:34 EDT 2007
Dirk Haun wrote:
>but something
>happened and APE wasn't able to edit the newly created entry afterwards.
Okay, I think I know what happened: APE tried to create an entry with this ID:
<id>tag:tbray.org,2005:161750213159936520861473325033</id>
Apart from it being > 40 characters, it also contains characters that we
don't allow (the colons and the comma) and replace. So the entry was
created with a sid of
tag-tbray.org2005-1617502131599365208614
As mentioned before, we need some logic to detect that the ID is too
long for us. I've previously stated that we also need to return the
entire atom:entry in the response, but that was wrong - sorry. RFC5023
clearly states:
> 2. If the Member Resource was created successfully, the server
> responds with a status code of 201 and a Location header that
> contains the IRI of the newly created Entry Resource.
We're doing that, only with a wrong ID ...
And while I'm correcting myself:
> We talked about it before: The service document (aka introspection)
> should return both workspaces per default, i.e. for the stories and the
> static pages. That's probably not as trivial to implement as it may sound.
The distinction is somewhat arbitrary but I think that should be _one_
workspace with two _collections_ in it, one for the stories and one for
the static pages (and additional collections for any other plugin that
supports webservices).
APE was also complaining about missing app:edited elemements:
>9 of 9 entries in Entry collection lack app:edited elements.
That should be easy to fix. Since we only have one date field in stories
and static pages anyway, we would return the same here as for atom:updated.
Ramnath, let me know if there's anything on the above list that you want
me to do. Otherwise, I'll leave them to you to fix.
bye, Dirk
--
http://www.haun-online.de/
http://spam.tinyweb.net/
More information about the geeklog-devel
mailing list