Make issues for each of the api facets

As none of these are feature complete make an issue to track progress for each..

This is administrative reminder.

if you want to know where to help look at failed tests of qunit.html (the homepage of the project) to see where there are gaps.

[ShellyMao]

I am looking through all the failed ones right now. Looks like there are gaps (i.e. Search tests) but perhaps some documentation could be helpful.
For example, when to use ok(false, "always fine") and how many results should be expected in each test and what each test is for. I know the test name is very self-explanatory but more documented specifications would be helpful. I am happy to start drafting for the existing tests here if you guys also think it is a good idea.

I've been using the 'ok(false, "always fine") ' test as the first test in creating a new handler. If it remains it is acting like a flag that real tests and functionality is yet to be built. Depending on the handler some will require Open API code to get to meta data or operations on content groups and user groups that aren't exposed in any other way.

I've been aspiring to a TDD model which is write a test first. It will be a failure then write the feature to fulfill the test. The test as you suggested becomes somewhat self documenting.

I consider this early alpha stage still so I've been favoring building to get enough together to share. I think as we are opening this up it is the right time to focus on more documentation and specification.

I won't get much time until July for any focus on this. In the interim if there is a handler that you deem useful I'd suggest maybe making a thorough test set for it and use that tests to define what should be added to the wiki under API Functions
https://github.com/solutionexchange/DSaaS/wiki/REST-API-Functions

We could probably use a post on practices for collaboration at some point but I don't want to dictate anything to a community that has yet to form around this API.