A few notes to add to this discussion. Whatever we use, I think the IDs surfaced by the REST API do need to be persistent. They need not necessarily be globally unique/persistent (like a handle or DOI), but they should be persistent within DSpace, obviously. Without a persistent identifier in place, systems built on the REST API (e.g. integrations or even new UIs built on REST) will be unable to accurately identify objects within DSpace.
Database IDs are definitely *not* persistent. They are just an incrementing ID, and that ID changes if you move an object from one DSpace to another. It's worth also pointing out that the AIP system does NOT persist database IDs (and says that explicitly). So, even restoring content from AIPs will often not provide the same Database ID. It'd be unfortunate if upon restoring content to your DSpace (from an AIP), it's no longer available at the same location from the REST API. Currently our only DSpace persistent IDs to choose from are Handles and now DOIs (in 4.0). I see no reason why we shouldn't use either (or both) of these in the REST API, especially since we have no other DSpace PID or UUID to work from (at least not yet). We don't necessarily need to identify what the persistent ID "means" via REST API. But, it should be persistent. Therefore an identifier: http://localhost:8080/webapi/content/collection/12.34/56 could be either a Handle (hdl:12.34/56) or a DOI (doi:12.34/56) or some other sort of PID. We don't necessarily need to specify which it is (at least not on the URI). But we do need to ensure it is unique and persistent within DSpace. That way if someone requests 12.34/56 today, and also requests it a year from now, they should be getting the same object from that particular DSpace. Unfortunately, that's not a guarantee we can make with Database IDs, as nothing in DSpace ensures their persistence after upgrades or data migrations or restorations from backup. - Tim On 11/8/2013 12:18 PM, Mark H. Wood wrote: > Thinking about this a bit more, I've come round to the position that I > don't see why database record IDs are a problem in this context. All > we need to do is to inform people that we explicitly deny long-term > meaning to these identifiers; they should be assumed to have session > scope. If you store one and expect it to refer to the same object > after your program exits, you are breaking the rules and may get the > confusion that you deserve. > > If you happen to notice that they seem to correspond to database > record IDs, that is not a guarantee that they will continue to do so. > > If you happen to notice that they seem to persist for months or years, > that is not a guarantee that they won't be different tomorrow. > > > > ------------------------------------------------------------------------------ > 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
