I don't think I'm able to see too far into the future on this (or any) API.
I see it as more a means to an end. This new machine interface will be a
pleasant way to get data out of your repository, repurposed into other
systems. Clients of the API should expect a stable interface for a period
of time, that they can build applications/uses against. I'm not envisioning
long-term-persistent API, but if you know what your looking for, it will
give you a way to use it.
A quick-win (not quick enough for 4.0) would be to introduce some type of
UUID on objects. They should be some type of globally-unique ID, I don't
see this being used for citation purposes, but if a collection, and its
content were moved from one repository to another, if it could retain this
UUID, and you can keep referencing the same identifier. Overcoming the DB
incremented entity ID, and not binding yourself to an overloaded handle.
Then regarding the entity vs entity-lists. I think the route that I'm
currently on _could_ be a bit bloated, where you request a specific
community, and you can also bring along its child-collections, and
child-communities. It might be cleaner / more-restful to move that
expansion, or just provide some syntax sugar to ask for a more restful
expansion, i.e. /communities/123/collections and
/communities/123/communities and /communities/123/items. Such that the
"communities/" returns a entity-list, i.e. community list,
"communities/123" returns a singular entity i.e. community, and so on down
the line.
I haven't touched the REST API for the past week to let some of the dust
settle, but I am in favor of wrapping responses, and including the request
context, so that regarding pagination, you have enough state/hints to know
how far you can paginate to. We do have limit and offset present currently,
so you can form your own pages.
Peter Dietz
On Fri, Nov 8, 2013 at 10:49 AM, Richard Rodgers <rrodg...@mit.edu> wrote:
> Hi Mark:
>
> Thanks for the thoughtful response.
> The point about handles was not intended to enshrine that particular ID
> system;
> I meant it as illustrative ("persistent IDs, _such as_ handles"). I
> certainly agree that
> a REST API should not enforce any particular scheme, and we have made some
> headway in abstracting identification services in the platform.
> If your persistent ID of choice is something else, the the REST API should
> expose it.
>
> Whether the use of Handles is appropriate (if that's your ID system) in
> this context,
> or whether DSpace needs a new persistent ID system with the
> characteristics you outline is more debatable I think,
> and raises many thorny questions (if only locally unique, how can content
> stewardship be transferred without collisions?, etc)
> that are quite important, but I think to some degree orthogonal to the
> REST API design features I was trying to point out.
>
> But point definitely taken, and I'll try to use more neutral descriptions
> (PID maybe?), which I agree is the issue at hand here.
>
> Richard R.
>
>
> On Nov 8, 2013, at 9:51 AM, Mark H. Wood wrote:
>
> > I want to look over this posting more carefully, but I did want to get
> > one thought out quickly. Please, let's not overload Handles even
> > more. There are sites, I've heard, that would like to do away with
> > Handles and use something else for durable universally-unique external
> > identifiers. That's hard to do if we wire Handles into everything.
> >
> > What we want, it seems to me, is an additional durable identifier
> > which requires only local uniqueness and has *no meaning* in
> > isolation. The last property excludes Handles and DB IDs alike. What
> > this means is that we need, probably, just a simple serial number
> > facility, which is used to name every object created. These names are
> > not used internally by DSpace (as DB IDs are); they exist solely for
> > users to identify "that object you mentioned before".
> >
> > This way, those names can be permanent (unlike DB IDs), don't tie us
> > to specific external services (like Handles), and can't tie us down to
> > specific internal organization (like either).
> >
> > --
> > Mark H. Wood, Lead System Programmer mw...@iupui.edu
> > Machines should not be friendly. Machines should be obedient.
> >
> >
> ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models.
> Explore
> > techniques for threading, error checking, porting, and tuning. Get the
> most
> > from the latest Intel processors and coprocessors. See abstracts and
> register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk_______________________________________________
> > Dspace-devel mailing list
> > Dspace-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
