Hi,
about the identifiers, I guess one must agree on what we expect from them.
We cannot forget that there is already the OAI interface which is meant to
guarantee some persistency and uniqueness over the identifiers.
Thinking about Rest APIs in general, they emerged as a simple way to access
data in a machine-to-machine communication.
I guess the best thing to do is to think about the majority of the usages
we might get.
Conceptually, UUIDs are important for cross domain access and I really
don't know if we need such properties for our IDs. This could lead us to
produce a completely flat API with CRUD operations over all objects
identified by some UUID.
I wouldn't use handles also as it concept is tied to another domain (unique
URLs).
I would say that, for the majority of the situations a structured API with
Local IDs would be more than enough.
Have a look at the following post, it could bring some light on what should
the API look like.
http://blog.parse.com/2013/10/02/parse-developer-day-video-series-how-to-design-great-apis/
On 8 November 2013 18:18, Mark H. Wood <mw...@iupui.edu> 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.
>
> --
> 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
>
>
--
Thanks, João Melo (My Portfolio <http://www.lyncode.com/m/jmelo/>)
DSpace Department
*Lyncode*: Official
website<http://www.google.com/url?q=http%3A%2F%2Fwww.lyncode.com%2F&sa=D&sntz=1&usg=AFrqEzdV8iS6rMxflxnn138XReuRfUG3OQ>
[image: Follow us on
Facebook]<http://www.google.com/url?q=http%3A%2F%2Ftwitter.com%2Flyncode&sa=D&sntz=1&usg=AFrqEzeDuT3ZqMW5uVIA8AoxtTtAeiCX3Q>
<http://www.google.com/url?q=http%3A%2F%2Fwww.facebook.com%2Flyncode&sa=D&sntz=1&usg=AFrqEzcWXjHa3gKBGLsNVxktapxkiWDnww>
------------------------------------------------------------------------------
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
