=head1 TODO

double/tripple query execution on items! and with/without me. (SQL differs by prefix on pk.)

This is all fairly random.

Things to do, or at least consider, before we stop being alpha:

    Test string keys, including unicode
    Look into at least basic support for documentation links in HAL
    Profiling

    Tweak test schema so FK field names don't match the PKs
    Test using a non-pk indentity eg genre name
    Add tests for links being present, correct, and working

    Support CODE ref relationship conditions

    JSON API:
    * warn at build-time if a resource has attributes that clash with reserved keys
    eg id (that's not the unique key being used for id), type, href, or links.
    http://jsonapi.org/format/#document-structure-resource-object-attributes
    * add optional resultset-class to jsonapi-type name mapping

    Refactor ::WebApp
    - move HAL browser out somewhere and mount via .psgi file
    - move/rethink My::HTTP::Throwable::Factory package block
    - move mk_generic_dbic_item_set_routes out to new module
    Leave just calls to mk_generic_dbic_item_set_routes and the construction
    of Path::Router - though even that could be moved to a better home.

    Review authorization handling and explore alternatives.
    Document 'basic auth on internet needs https', see also:
    Also http://stackoverflow.com/questions/17530992/authentication-and-or-https-with-plack-psgi-poet-application/24808547#24808547

    Review code for DBIx::Class sanity and best practice

    Support non-primary unique constraint as identity

    Refactor param handling to abstract ~json both for requests *and* constructing
    link urls (where json data isn't fully handled at the moment, other than pass-thru).

    Any security issues with allowing arbitrary json in parameters?
    Should we allow use of relationships in conditions that aren't exposed as routes?
    (perhaps make that optional per class and default off, maybe allow via regex on relname)

    Allow (and prefer?) prefetch=me over prefetch=self?

    Adopt Log::Any for logging and debug?

    Review code and docs for XXX / TODO /TBD markers

    Better test coverage, especially for roles

    Documentation

    WebAPI::DBIC::Resource::Role::DBICException finish_request() figures out
    invalid fields by doing regex matching against database error messages.
    The current regex works for Pg and SQLite, probably won't work against other
    databases.
    fREW has some code on L<https://github.com/frioux/DBIx-Exceptions|github>
    for matching the error messages. That plus L<DBIx::Introspector> could do the trick.
    (Another alternative would be to build a valid parameter list while we're
    introspecting the schema, but that wouldn't catch many other kinds of exceptions.)

Other items:

    Refactor transaction handling.

    Better error reporting (in HAL format)
    Reconsider and/or polish HTTP::Throwable::Role::JSONBody
    Handle and report parameter validation and db constraint errors in a way that
    allows sufficient information to be returned to the caller e.g., to mark which
    fields of a web form hold invalid values.

    Review Moo usage for best practice
    especially Roles and before/after/around

    Profiling, especially re the cost of constructing relationship links
    for each item. Much work could be cached to make it much cheaper.

    improve partial response support for prefetch

    Consider how to handle multi-field primary keys and foreign keys

    Reconsider using or removing unused code from ::Util
    (I think only create_header is used at the moment)

    use HAL CURIE prefix in link keys?

    make it easy to limit fields returned by default so new apps can adopt that
    as best practice - add to the code on demand, so we know the
    fields are actually being used and the inverse, that we can remove/change a
    field that's not being exposed and know that no users of the api will be affected.
    Perhaps allow DBIC resultset classes to define what default set of fields to use.
    Note effect on caching.

    Support multiple $schema's? With cross-schema linking?

    Consider async?

    Look for further ideas in
    https://metacpan.org/module/Catalyst::Controller::DBIC::API

=head2 HTTP Caching

Explore of HAL item caching using ESI or SSI

    https://metacpan.org/pod/Plack::Middleware::ESI
    http://wiki.nginx.org/NginxHttpSsiModule

The cached urls would need to include extra params like fields=...

So it's possibly better to use a surrogate key approach:

    http://www.hward.com/varnish-cache-invalidation-with-fastly-surrogate-keys
    https://www.varnish-cache.org/utility/secondary-hash-hash-ninja

which would need some support in WebAPI::DBIC to pass some kind of cache key
through the code to include in a response header.


=head2 HAL Browser

To update:

    git subtree pull --squash --prefix hal-browser git@github.com:mikekelly/hal-browser.git master

=head2 Other Test Schemas

See the run-chinook-demo.sh script for a quick way to run the code with the
Chinook sample database from http://chinookdatabase.codeplex.com

=cut
