Hi All,
The Jersey REST API that shipped with DSpace 4, lets call the DSpace REST
API v1. (Yes, there were other API's before it, Hedtek, Wijiti, GSOC). In
DSpace 5, the REST API is still based on JERSEY, and it will add CRUD
operations.
See demo of DSpace 5 CRUD REST API:
https://www.youtube.com/watch?v=Ba9TL1Pl5pw
This CRUD API is very similar to the existing read-only API, the structure
of most responses is very similar. But, there are some minor tweaks. So,
I'm wondering what the advice of the crowd is? Should we just have DSpace 5
ship with a changed API? Or should we bother with "versioning" the API?
i.e. DSpace 4 Read-Only API to be available at: /rest/v1
and DSpace 5 CRUD API to be available at: /rest/v2
?
Thoughts...
I'm not sure how widely used the existing READ-only DSpace 4 API gets. i.e.
If you didn't use DSpace 4 rest, then there's nothing to worry about. But,
if you have built some integrations / apps on the DSpace 4 API, there will
be the minor changes... So, what's to best way to inform API consumers that
when you upgrade these are the changes that you need to make to your
consumer app immediately. Or, do we go the extra mile now to add api
versioning (which unfortunately would need to be
yet-another-thing-to-spend-development-time-on, and
yet-another-thing-to-support).
________________
Peter Dietz
Longsight
www.longsight.com
pe...@longsight.com
p: 740-599-5005 x809
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
