Releases: blomqma/next-rest-framework
v3.1.0
v3.0.1
v3.0.0
Changed
This is another breaking change before another
major release. This mostly changes the API on
creating new endpoints. The old object-based
definition of API endpoints is replaced by
a functional model, familiar from e.g. the trpc
library.
The docs route handlers and route handler functions
are renamed, followed up with new utility function
used in conjunction with the new routeHandler
and
apiRouteHandler
functions. The new additional
routeOperation
(App Router) and apiRouteOperation
(Pages Router) functions expose the same old API
including the input, output and handler definitions
in a slightly new format by chaining the oprations
after each other.
We also recently dropped SwaggerUI that was replaced
by Redoc. This change allows the user to defined their
desired docs frontend, bringing back the option to
use SwaggerUI or even both Redoc and SwaggerUI at the
same time.
Fixed
This fixes the query parameter typings
that were incorrect for both routers so that they
are safer to use.
This also fixes duplicate inclusion of the parameters
in the OpenAPI spec when using dynamic routes.
There are also some typings improvements for response
status codes, that we're not working previously.
Unfortunately, for App Router the status codes are
still not limited to the user-defined response statuses,
because the NextResponse
API makes this impossible.
v2.0.1
Fixed
This fixes a bug that caused an infinite request
loop when using pages router and the docs endpoint
was not ignored by the OpenAPI path generation.
This fix also allows defining multiple different docs
endpoints, although that should be a rare case.
The request protocol parsing is also now handled
differently with pages router and cases where the
protocol headers contain multiple protocols should
be handled now.
v2.0.0
Improve DX, API docs, router compability etc.
This is another breaking change to multiple
components of the framework, changing the client
API, simplifying route definition etc.
Re-designed client API
Previously all features of the framework were
available via single client, initialized by the
user in their code base. This change removes the
concept of initializing a client and accessing route
definitions etc. via the client.
The documentation part is now decoupled from defining
individual routes, meaning that the new simplified
workflow allows the developer to define a single route
for the generated documentation if they want it.
Individual routes can still be defined like before,
without importing the route definitions from the client.
The documentation endpoint also does not have to be a
catch-all route and it can be defined anywhere in the code
base without breaking things.
In addition to having less boilerplate with the new
client API, we also get rid of configuring the paths
for the app
and pages
directories. The new smarter
approach handles this automatically by scanning these
folders automatically, detecting the src
directory
is in use.
Streamlined OpenAPI spec generation
Previously, we were storing the generated openapi.json
file in the root of the project and serving that via another
internal endpoint. The new approach simply generates the spec
file directly to the public
folder, where it will be served
for the API documentation.
Replacing SwaggerUI with Redoc
Redoc is a great open source project and replacement for
SwaggerUI, offering more features like richer endpoint
previews, search etc. The new rendered API documentation
uses Redocly and it can still be configured and customized
by the developer.
v1.2.4
v1.2.3
v1.2.2
v1.2.1
v1.2.0
Added
- Add option to allow/deny paths from Next REST Framework. This ensures better compability with other third-party server-side libraries and routes not using Next REST Framework.
- Add logging for error cases when the app/pages directory is not found based on the config options.
- Add logging for ignored paths based on the allow/deny lists.