Why not adopt me?
This distribution is up for adoption!
If you're interested then please contact the PAUSE module admins via
email.
TODO
Things to do, or at least consider, before we stop being alpha:
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 CODE ref relationship conditions
META - including RT or github issues?
consider how to handle non-integer primary keys, probably trivial.
also relates to improving the separation between resources and records
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).
Consider abstracting the interface to Path::Router so other routers can be used.
Any security issues with allowing arbitrary json in parameters?
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
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
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.
HAL Browser
To update:
git subtree pull --squash --prefix hal-browser git@github.com:mikekelly/hal-browser.git master
Other Test Schemas
Here's a procedure to test WebAPI::DBIC with the schema/data from RA::ChinookDemo (http://www.rapidapp.info/demos/chinook) Based on https://gist.github.com/vanstyn/c2e42944f8453a910ccf
git clone https://github.com/IntelliTree/RA-ChinookDemo.git
export PERLLIB=RA-ChinookDemo/lib
export WEBAPI_DBIC_SCHEMA=RA::ChinookDemo::DB
export WEBAPI_DBIC_HTTP_AUTH_TYPE=none
export DBI_DSN='dbi:SQLite:RA-ChinookDemo/chinook.db'
plackup -Ilib webapi-dbic-any.psgi