Began working on debug handler and pathing

References Issue #100

Added a controller to handle the client-side debug reporting and the
neccesary pathing changes on the api.
Merge branch 'develop' into feature/client_reporting
Added bug retrieval and json formatting. next will be bug deleting.
Initial Spec on debug endpoint

References #100

Updated specification for api to include a possible scheme for the debug
endpoint's interface. This is subject to change upon discussion with
@the-hobbes

The error codes portion of the specification is not done and probably
won't be done until we decide on the spec and the validation code is
written. Currently, the endpoint functions for GET and POST requests
exist but does nothing. The DELETE handling functions are not
implemented yet. POST has some small degree of validation but nothing
endpoint specific yet (only json validation).

We need to determine our strategy for dealing with authentication and
deletion of messages. We'd like to allow a client to delete their own
messages if they don't want to be transporting that data to us (or be
able to shut off reporting on their end entirely if we feel its a legal
issue. ) Currently the spec states an origin/master key policy. Where we
can use salt + device id to determine the originator of the debug
message and use that as part of validation before deleting a message.
Also, a master key for developers could exist. Either that or we just
allow devs to delete reports through the app engine console. But this is
horribly slow and it'd be nicer to automate it.
Merge branch 'feature/client_reporting' of github.com:EJEHardenberg/GreenUp into feature/client_reporting
Updated POST debug endpoint with example body

References #100

Added an example json message body to the POST request specification. We
should determine the hashing algorithm we'll use for device id hashing.
It does not need to be a slow one and should be fast. No need to slow
down the client for just reporting.
Example delete request for debug endpoint

Reference #100

Added example of sending a DELETE request. Note that the DELETE verb
does not take its arguments in a message body, but in the url itself.
This is according to the HTTP spec. Since we are deleting simply by a
resouce identifier, aka, the URI. It might be more semantically correct
if we had the url be /api/debug/origin?hash= but I'm not sure how to do
that with python and placing both into the DELETE url parameters should
work just fine.
Work on Enhancement #101 (status codes)

Implementing the changes discussed on github issue #101. Including a
status_code key into the response from the API so that all information
is within the json as well as the HTTP headers.

Implemented changes on comments endpoint and updated spider to test
these changes.
Work on Enhancement #101 (status codes) on heatmap

Implementing the changes discussed on github issue #101. Including a
status_code key into the response from the API so that all information
is within the json as well as the HTTP headers.

Implemented changes on heatmap endpoint and updated spider testing to
assert that this is true. Spider passes, so it's working.
Work on Enhancement #101 (status codes) heatmap.

Continued work on heatmap endpoint. This is a breaking change for the
API clients because it modifies the heatmap to return a json object
instead of a json array.

The new json object has keys of status_code and grid. The value of the
grid key is the old json array that the clients using the outdated API
will be expecting.

An idea has just occured to me. I will update just the appspot api
site and clients can use that to test their work against the new API
while still using the old version from the app site.
Work on enhancement #101 (status_codes) pins

Implementing the changes discussed on github issue #101. Including a
status_code key into the response from the API so that all information
is within the json as well as the HTTP headers

This is a breaking change to the pins endpoint. The json response
returned will now be an object, not an array. The object has both a
status_code and a pins key. The pins key value is the array that was
returned before this change occured. The status_code is the HTTP
response code also included in the headers.
Removed extra logging

Removed some debug logging from the pins response.
API Specification update

References #101

Updated specs to have the proper status_code's for each endpoint within
the example response.
API endpoint updated for status code

Progress on #101

Added status_code to plain /api endpoint for consistency and to adhere
to the updated API specification
Updated GET debug endpoint and specs

References #100

Created GET processing and parameter validation for debug endpoint of
API. Updated API specification (we should think about changing the
readme.md file to just be spec.md or something, except then it doesn't
get rendered on the front page of github directory... symlink?)

Updated constants with an ERROR_STR variable that will be useful for
unifying the error response from the API when problems occur.
Implemented POST validation for debug endpoint

References #100

Implemented POST validation against post data keys and values. Updated
API specification to list possible errors and their causes for the
endpoints responses to POST requests.

No hook-up to the datastore yet for either GET or POST endpoint. But
deletion endpoint will need to be worked on next.
Added DELETE debug endpoint

References #100

Added support to respond to HTTP DELETE request to debug endpoint.
Documented error responses currently returned. There will be some
additional error responses once we've determined the exact response from
the underlying abstraction layer. Probably a 404 message for when the
origin/hash pairing does not match to the database.

Also, the delete endpoint should probably refactor to return a 204
status code on success. See the relevant stack overflow post:
http://stackoverflow.com/a/6440374/1808164
Extensions to spider for delete endpoint testing

References #100

Working on extending the spider for the debug endpoint. Added testing
and validation for POST and GET endpoints of debug endpoint. All is
working as expected. I foresee some trouble with spidering the DELETE
request only because we need the datastore to be operational in order to
properly validate it.
Updated spec on debug endpoint

References #101, #100

Updated spider to perform all but one check (the check is not possibly
until the abstraction layer is complete).

Updated spec with note about status code 204 and the DELETE request
response being an empty string. How to handle this is listed as a
comment by myself on issue #101 on github.
Updated datastore to handle debug

References #100

Added origin field to debugMessages. Added methods to debugReports by
their origin, hash, and since time.

The biggest change is to the paging function. Instead of being strictly
limited to using the comments. It now takes a few extra parameters and
handles the paging properties for both the debug endpoint and the
comment endpoint. While coding this, I was thinking perhaps we should
extract the paging strategy into its own class or maybe a function that
takes a list of items to create the paging for and then returns it up to
another function that handles the formatting and endpoint specific
features.

Posting to the debug endpoint now creates a debugReport object as well.
So that portion is functional. Only responding to the DELETE verb needs
to be done.