Datasets V3 API clean up


Release Notes



Albert Shau
March 3, 2015, 9:19 PM

discussed with , we will keep the API the same for getting a single dataset, but change the API for getting a collection to return a collection of name and type instead of a collection of specs. There also seems to be work going on in parallel that will remove "cdap.default" from the name in the spec.

Albert Shau
March 3, 2015, 8:43 PM

I think we can change the GET /data/datasets call to return objects with an id field and a spec field. That will at least make the hierarchy consistent between the GET calls and actually allow somebody to get a specific dataset.


Albert Shau
March 3, 2015, 12:22 AM

Couple issues with the current /data/datasets APIs.

1. GET /data/datasets returns names like "cdap.default.whom", but these cannot be used in GET /data/datasets/<id>. You do GET /data/datasets/whom, not GET /data/datasets/cdap.default.whom.

2. GET /data/datasets returns dataset specs, which is inconsistent with GET /data/datasets/<id>, which returns "spec" (which matches the GET /data/datasets call) and "type". These are all different than the PUT /data/datasets/<id> call, whose body is a "typeName" and string map of "properties"

Albert Shau
March 3, 2015, 12:10 AM

The /datasets endpoint actually seem more RESTful than the /data/datasets endpoints. I think we would have to do some clean up on the /data/datasets endpoints as well.



Albert Shau


Sreevatsan Raman