Two questions about the new CC Rest API version . . .
How will the new work-information elements be reflected in the service response, e.g will the rdf, rdfa and html in a license issue change, or just a subset of those areas of the response document? (The documentation shows a standard response from the currently released api.
When can we begin using the staging api? We are migrating our repository software to a more recent version, and require CCO. I expect our upgraded software to go into production in the first week of June.
..\Wendy Wendy Bossons Web Developer MIT Libraries Technology Research and Development 77 Masachusetts Avenue Cambridge, MA 02139-4307 617-253-0770
Hi everybody,
I'm delighted to announce that we've recently updated our REST API
with some exciting performance enhancements, bug fixes, and
improvements to the developer documentation!
The most up-to-date version of the CC REST API is now rooted at
http://api.creativecommons.org/rest/staging/.
To read more about this release, visit the staging version's
documentation.
http://api.creativecommons.org/docs/readme_staging.html
The staging and development APIs are currently in beta, and we
are soliciting feedback and suggestions. As such, the API may
change in the future.
The staging version of the CC REST API has been entirely rewritten
to be more maintainable, faster, and stable.
Boasting points:
* Cleaner CC0 implementation
* Lightened dependencies
* Ease of extensibility
* Improved documentation
* Comprehensive and rigorous test suite
* CC "sanity" work use case!
To iterate on a couple of those points:
Improved documentation --- The main focus of improving the REST
API's documentation was to reduce the amount of confusion
surrounding how the individual work-info elements affect an
HTML+RDFa license result. The most up-to-date documentation for
this release can be found at http://api.creativecommons.org/docs/readme_staging.html#providing-work-information,
which elaborates more on this issue.
CC0 --- In order to get CC0 into previous versions of the REST
API, a grotesque monkey-patch was required [1]. The patch resulted
in longer response times for CC0 issues than the typical latency
experienced with the standard licenses' requests. This has been
resolved in the latest release, and the CC0 integration has been
tremendously improved. We have also corrected the inconsistencies
that existed between CC0 and standard license issues in how
work-info elements were handled in the HTM+RDFa output.
Some background on why this work was needed...
Historically, the REST API's issued parametrized license
results via the license_xsl library, the same library that powered
the license chooser accessible at
http://creativecommons.org/choose/. license_xsl relies on XML/XSLT
for it's core logic and over the years has become increasingly
difficult to maintain and bloated. This made things to difficult
to scale our services as the CC organization continues to grows --
recall how long it took for us to get around to supporting CC0 :)
license_xsl is to be relieved of it's duties at CC by the
cc.license project sometime here in the near future. The
newly built CC API is one such example of a license_xsl
decommission. The REST API is now backed by the cc.license
library, which provides the API's core logic for issuing licenses
based upon sets of user parameters.
Your comments, feedback and suggestions can be sent to
cc-devel AT creativecommons.org and are always very welcomed and
encouraged :)
Regards,
John Doig
JED3 @ irc.freenode.net/cc
[1] "insane monkey-patch":
http://code.creativecommons.org/viewsvn/api/branches/nose-test-suite-branch/support.py?r1=10185&r2=14085
<ATT00001.c> |
