mill
mill copied to clipboard
erunion
☴ An annotation-based DSL for documenting a REST API.
# Changed log - Fix Psalm analysis error - Removing some comment annotations because they're unused. - Adding the `pull_request` trigger to let upcoming PR can do GitHub Action work...
https://swagger.io/docs/specification/describing-parameters/#common-parameters Currently common parameters are duplicated across path methods, resulting in a lot of duplicate lines of code in generated specifications. Migrate these up into common parameters and save a...
Like with the `TagReducer`, it would be nice to have the vendor tag and private/public resource visibility filtering code decoupled into a separate tool that you could supply a full...
 This changeset is technically a change because GET `/users/:user_id/tickets/:ticket` was previously returning a `204 No Content`, and now it returns a `200 OK` with a full representation. - [...
With the new MSON work in #42, the syntax for referencing another representation in a representation data is: ``` @api-data director (\Mill\Examples\Showtimes\Representations\Person) - Director ``` This is fine, but it's...
Currently mill requires your PHP method to be named after an HTTP method. This seems like an unnecessary restriction. Lets discuss possible solutions in comments below.
Currently we have no way to document that a resource action returns a collection of a type of response. For example, in the Vimeo API: ```json { "total": 66, "page":...
``` @api-return {collection} \App\Response\Response1|\App\Response\Response2 ``` When compiled into OpenAPI, this would probably have to be an `anyOf` representation instead of our standard `oneOf`.
If you instantiate a new `Changelog` object with a version object (like say `