Why not adopt me?This distribution is up for adoption! If you're interested then please contact the PAUSE module admins via email.
This is all fairly random.
double/tripple query execution on items! and with/without me. (SQL differs by prefix on pk.)
Things to do, or at least consider, before we stop being alpha:
Explore using serializer and adaptor objects. Add some docs re choosing ActiveModel vs JSONAPI vs HAL even if just links Eg see http://discuss.emberjs.com/t/should-we-keep-using-ember-data/7405/10 Add tests and docs for RouteMaker make_routes_for args and options TODOs for JSON API: - provide "links" separately to prefetch logic - support collection urls, e.g. /photos/1,2,3 - support relationship urls, e.g. /photos/1/links/photographer - support include= in addition to prefetch= - support multiple sorts, e.g. sort[posts]=-created,title&sort[people]=name - support the "name[type]" style of field= param value - support creating resources via the application/vnd.api+json media type - support updating resources via the application/vnd.api+json media type - support updating relationships via the application/vnd.api+json media type 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 Implement ::SetInvoke (Ponder /foo/invoke/bar/drill/down/in/results) 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 * explore https://github.com/json-api/browser Document authentication and authorization Add eg _build_initial_search eg for 'show only records owned by current user' Mention https://metacpan.org/pod/DBIx::Class::Schema::RestrictWithObject 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 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? Note relevant env vars, eg WEBAPI_DBIC_DEBUG, PATH_ROUTER_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.)
Refactor transaction handling. Consider viability of reworking to be able to stream results using callbacks http://www.catalystframework.org/calendar/2014/11 Would presumably require a streaming JSON encoder (or encode row-by-row and fake a closing "]" at the end) 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 https://metacpan.org/pod/Leyland https://metacpan.org/pod/McBain https://metacpan.org/pod/Raisin
Explore of HAL item caching using ESI or SSI
The cached urls would need to include extra params like fields=...
So it's possibly better to use a surrogate key approach:
which would need some support in WebAPI::DBIC to pass some kind of cache key through the code to include in a response header.
git subtree pull --squash --prefix hal-browser firstname.lastname@example.org:mikekelly/hal-browser.git master
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