15 Dec
2008
15 Dec
'08
5:28 p.m.
On Dec 15, 2008, at 5:24 PM, Fabio Mancinelli wrote:
Vincent Massol wrote:
Not yet but we want to support this in the future yes so better design
a REST API that will work with nested spaces (arbitrary level yes).
Thanks
-Vincent
Hi Fabio,
Looks good. 2 questions:
1)
# /spaces/{space}/pages/{page}/translations[?start=offset&number=n]
(The list of all available translations of the page {space}.{page})
# /spaces/{space}/pages/{page}/{version} (The page {space}.{page}. at
version {version})
# /spaces/{space}/pages/{page}/{lang} (The page {space}.{page} in its
{lang} translation)
# /spaces/{space}/pages/{page}/{lang}/history (The list of all the
available revision of the page {space}.{page} in it {lang}
translation.)
# /spaces/{space}/pages/{page}/{lang}/{version}
This seems somewhat inconsistent with "pages", "attachments",
"objects"
Why not have "versions" and "translations"? For example:
/spaces/{space}/pages/{page}/versions/{version}
I thought that having shorter URIs would be better. But I am not
against
having something like
/spaces/{space}/pages/{page}
/spaces/{space}/pages/{page}/versions
/spaces/{space}/pages/{page}/versions/{version}
/spaces/{space}/pages/{page}/translations
/spaces/{space}/pages/{page}/translations/{language}
/spaces/{space}/pages/{page}/translations/{language}/versions
/spaces/{space}/pages/{page}/translations/{language}/versions/
{version}
Or similar.
Note that I don't know what are the REST best
practices. I'm jut
noticing the inconsistency.
URI design is not that important (as long as the hypermedia
constraints
is fully leveraged). However having descriptive URIs and consistent
URIs
can enhance the possibility of discovering resources by guessing (i.e.
the level of "serendipity")
2) How will we support nested spaces?
Actually I didn't address the nested spaces issue.
Spaces can be nested at an arbitrary level?