[cc-devel] New version of the CC REST API

John Doig john at creativecommons.org
Mon Apr 26 17:18:24 EDT 2010


  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 
<http://code.creativecommons.org/viewsvn/api/branches/nose-test-suite-branch/support.py?r1=10185&r2=14085> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20100426/49f608dd/attachment.html 


More information about the cc-devel mailing list