Previously, form and query parameters were handled together as
request parameters. Howeer, request parameters are a server-side
construct that's specific to the servlet specification. As such
they're not appropriate for the client-side documentation that
Spring REST Docs aims to produce.
This commit replaces support for documenting request parameters
with support for documenting query paramters found in the query
string of the request's URI and for documenting form parameters
found in the form URL encoded body of the request.
Closes gh-832
This commit adds support for JUnit 5 and its Jupiter programming
model. A new Jupiter Extension implementation,
RestDocumentationExtension, is provided. This extension can be applied
to a test class to allow it to use Spring REST Docs to document a
RESTful API.
Closes gh-296
This commit upgrades to Spring Framework 5.0.0.RC1. It also upgrades
the Spring Boot-based samples to use Spring Boot 2.0.0.M1 which
supports Spring Framework 5. Lastly, it upgrades a number of
third-party dependencies to align with Spring Framework 5 and Spring
Boot 2.
Closes gh-386
Previously, when a field was documented it would implicitly document
the whole subsection of the payload identified by that field. This
could lead to users inadvertently failing to document part of the
payload. Arguably, this was a bug as it violated REST Docs' principle
of producing accurate, detail documentation. However, fixing it
requires a breaking change as people may also be relying on this
behaviour. A balance needed to be struck so the fix is being made in
a minor release.
This commit introduces a new subsectionWithPath method which returns a
SubsectionDescriptor; a specialisation of FieldDescriptor. Users
that were intentionally relying on the old behaviour will have to
replace some usage of fieldWithPath with subsectionWithPath instead.
Users who were unintentionally relying on the old behaviour will have
to add some additional descriptors produced using fieldWithPath and
will receive more accurate documentation in return.
Closes gh-274
- Rebase on latest code, and make use of new support for the same
TemplatedSnippet producing multiple snippets with different names
from the same template
- Expand the documentation
- Apply code formatting
- Add support for relaxed documentation of a request part's fields
Closes gh-270
Rather than requiring an output directory to be explcitly configured,
a default is now automatically configured based on the build tool
that's being used. When using Gradle, snippets will be generated in
build/generated-snippets. When using Maven, snippets will be
generated in target/generated-snippets.
See gh-297
Previously, if alwaysDo was used and the user wanted to generate
one or more additional snippets when calling perform a separate call
to `snippets` was made prior to calling `perform`. This had two
problems:
- it required the result handler to be stateful (see gh-243)
- it wasn't clear that the additional snippets would be produced when
a subsequent call to perform was made
This commit introduces a new API that allows the additional snippets
to be specified within the MockMvc call. The old API has been
deprecated and will be removed in 2.0.
Closes gh-249
