Proposed changes to API skeleton

[weierophinney]

This patch accomplishes the following:

• Moves all "User" related classes into a single namespace, App\User. Grouping them together makes it easier to identify what goes with what.

• Moves exception handling and raising into the UserModel and RestDispatchTrait. This simplifies handlers by allowing them to worry only about marshaling request data, passing it to the model, and creating a response.

• Splits the handler into three, based on dependencies needed:

  • UserHandler needs on the model, resource generator, and response factory.
  • ModifyUserHandler also needs the input filter.
  • CreateUserHandler also needs the URL helper.

  It also splits the routes into three distinct options:

  • UserHandler optionally accepts an identifier
  • ModifyUserHandler requires an identifier
  • CreateUserHandler cannot accept an identifier

• Moves the ProblemDetailsMiddleware earlier in the pipeline, to ensure we catch any errors that occur during an API request.

• Removes the password from the UserEntity, to ensure we never display it over the wire. This is a best practice.

• Ensures OAuth2 works. It does so by doing the following:

  • Changes the zend-expressive-authentication constraint to 0.4.0, which is the first that supports PSR-15.
  • Changes the zend-expressive-authentication-oauth2 constraint to 0.4.3, which is the current stable, and has fixes that ensure no configuration errors block bootstrap of the application.
  • Adds documentation to the README on how to setup both the sample and OAuth2 databases.

• Adds examples demonstrating Problem Details.

• Creates new handlers in the App\Doc namespace that correspond to the type URIs of the Problem Details messages we emit. These are text/plain responses with human-readable descriptions of the problems we can raise.

I've provided ample documentation in the commit notes detailing each change as well.

[Rockstar04]

Not sure if this should be addressed here, or in the repo for ZendDB, but $this->table->lastInsertValue can return a string depending on the driver used, causing the examples as laid out here to break when trying to create a new user.

The UserInputValidator is also missing (possibly be design) a field for the users name, so creating a new user leaves you with a name.

[ezimuel]

@Rockstar04 if you think that lastInsertValue() has some issue please open it at https://github.com/zendframework/zend-db. Regarding the missing user name this is by design, becuase the user name is not required in the table. Thanks for your feedback!

[ezimuel]

@weierophinney thanks a ton for the awesome PR!

[weierophinney]

Actually, @Rockstar04 has a point: if the field is not defined, it will not be in the values pulled from the input filter (which is one change I made). We need to add all fields to the input filter; if they're not required, we simply mark them as such.

[Rockstar04]

@ezimuel ZendDB's AbstractTableGateway.php does not declare its return type (other than in its docBlock), but UserModel.php sets a return type of int with no validation or guarantee that that the table gateway has actually returned an int.

[ezimuel]

@Rockstar04 ok, I misunderstood your original proposal. I already merged your PR. Thanks!