Passing the debug flag to provider and attribute filters can allow them to behave differently when in debug mode.

E.g authentication in production could be against LDAP where as during development we can simulate a username and password.

Async Integration with something like Google analytics, this feature will be implemented in two portions:

• Logging of API traffic, this will involve logging the accessed pattern along side the accessed URL. To effective create statistics for API we need to log the URL patter of the API end point
• Logging endpoint URLs with specific IDs or values will make it harder to run statistics, more over the patterns would have to be updated as the API is updated
• The request router will be able to inform the log of the available / registered URLs.
• The log would then be processed asynchronously and the data would be pushed to an analytics service like Google Analytics or Piwik for visualisation.

Should be ok to use now but needs testing before issue can be closed.

1.x sends response attribute list as part of the GET request. Replace this with a custom HTTP header to make the request cleaner.

A standard "python setup.py install" does not install the directories 'ext' or 'tools' or any contained files. I had to manually copy these into the site-packages\prestans directory.

I tested this under a virtualenv setup, both on OSX and Linux (Ubuntu derivative), both Python 2.7.

Instead of URL separating serialisation format use HTTP request headers

• Client sends in an Accept Header, if the REST application supports the format it sends back a response
• REST service can choose not to respond in the requested format (e.g Binary formats)
• If a format is not supported by the application a standard error message is generated
• Developer no longer has to register different URLs for separate formats

Questions:

• Is allowing different formats for request and response a valid interaction?

• Partial implementation available for Blueprint API
• Add information about authentication

Current thoughts are to allow the developer to handle exceptions thrown from the handler method before the default prestans catches take effect.

This will hopefully allow more meaningful codes/messages in the event of a failure instead of 500 all the time.

This is mainly for app engine when there are common framework exceptions that you want to handle in a fixed way.

• Two error messages are rendered in HTML
• Used bootstrap for prototyping
• Not to be distributed with that dependency

Provide a unified command line tool for project management, testing and auto generation.

Will replace preplate, presh and other utils.

Introduce an API / feature to allow automatic throttling of queries being sent to each handler.

Array should throw exception if no element template provided.

If authentication is enabled, prestans still attempts to parse the request body before executing the authentication checks.

Authentication should take precedence over parsing.

NDB does not return structured properties via getattr
https://developers.google.com/appengine/docs/python/ndb/properties#structured

Add support for Time type

Response filters are not being applied and full bodies are being sent back.

Investigate data adapters to see if property existence checks are also calling properties, ie, will properties be called twice when a data adapter is run.

This could pose performance problems for app engine.

When sending POST requests; if Content-Type is not provided prestans sends back a 501 Not implemented with no body.

Consider adding constants for blueprint and preplate type strings.

This could be placed inside a Meta class block for each type.

Preplate and blueprint should then make reference to these as opposed to hard coding strings.

DataAdapters originally had the idea of adapting rest models to persistent models. It was brought up by @rasjidw on the list.

Major issue was that when copying data back from rest models to persistent models; one typically copied a selection of attributes, depending on the handler action.

Initial ideas to do this was introduction of an configuration per attribute.

AttributeFilter should be able to fill this gap in and allow iteration of selective attributes.

Request body parsing should check value of body_template and ignore if None.

Should we do it?

If so, what changes will need to be made to add this functionality.

Further thoughts would probably be best done by addition array classes such as:

• Array2D
• Array3D

Anything beyond this is probably superfluous

• Writing Cookies is not supported at the moment by prestans.rest.Response
• Attempt to maintain how applications use the response object
• The way RESTApplication will write their response will change refer to Webob documentation and source

Currently doesn't show up attribute names for sub model validation.

Restore a stack trace style message.

Data Validation errors to use blueprint api to present detailed description of acceptable data for attributes

There is no need for the warning for an empty body if status code is No Content.

E.g usage of a custom AttributeFilter instance for request parsers. At the moment the developer has write something like:

filter = AttributeFilter(Model())
filter.attr = False

be nice to support *kawrgs to allow

filter = AttributeFilter(Model(), default_value=False, attr=True)

issue being sub filters cannot be addressed in the constructor.

Look into rewriting response bodies with arbitrary keys which can then be substituted by the client.

So something like:
{
"key": "value",
"longer_key": "value2"
}

becomes:
{
"a": "value"
"b": "value2"
}

Initial sample estimates show between 25 to 40 percent size savings are possible.

The substitution dictionary could be passed via HTTP headers.

response_attribute_filter_template should really be constructed of response_template

This will require some reworking of preplate but the plan would be to allow a separate prestans-server and prestans-tools python packages so the server install is as minimal as possible and the tools package is only needed on development machines.

Fill out error messages in exception classes

An issue was discovered where accessing the URL params of a POST request would then corrupt the body and not allow it to be read.

It has been currently patched by fixing order of operation but this should be revised to check:

• Is this valid under HTTP?
• Can it be done differently under webob?
• Are there other solutions apart from webob?

Features:

• Restore serialisation code in new Response class
• Restore request and response parsers
• Restore attribute filters
• Restore parameter sets
• Restore authentication provider
• Restore authentication decorators
• Error message serialisation to responses
• Restore Data Adapters

Testing:

• Test model parsing

Enhancements:

• Update regex match for router
• Throttle provider
• Cache provider

Documentation

• Finalise documentation pattern

Currently data adapters use hasattr() to check for the existence of attributes on the persistent object, however hasattr fails if any Exception is thrown in the property/attribute.

This makes debugging difficult as it can hide errors in properties by treating them as non-existent attributes instead of throwing the correct exception.

An alternative approach would be to use something like the following, explicitly checking for AttributeError:

try:
getattr(someObject, 'someProperty')
except AttributeError:
print "Doesn't exist"
else
print "Exists"

This error is also present in the SQLAlchemy data adapter where it hides any DetachedInstanceError exceptions that are thrown when trying to access out of session objects.

Like webapp2 or other routers; ensure that prestans respects thread safety

http://pythonpaste.org/modules/registry.html

Default values are not present in fields.

Could possibly be an issue with one of the following:

• Filters being applied
• Default only being set when validate is called

• d89c599 changes dict for arrays to getattr in attribute filters
• In light of this see if others needs a revision

Proposed future feature to include a client side data caching proxy.

Would make use of the following technologies:

• Http ETag
• HTML5 Local Storage

Implementation to mimic NSURLRequest layer in Cocoa, clients will place requests every time, the cache provider will check if the request was recently placed and return the same result.

Requests have to be able to indicate which methods are cacheable.

parameter set -> get_cache_key

• Types
  • String
  • Integer
  • Float
  • Date
  • Time
  • DateTime
  • Boolean
  • Binary
  • File upload
• Request Handler
• Request Router
• Request
• Response

Make sure that all packages and handlers are using consistent error messages and exceptions.