This commit adds a new andWithPrefix(String, FieldDescriptor[]) method
to both RequestFieldsSnippet and ResponseFieldsSnippet. It can be
used to add descriptors to an existing snippet, applying the given
prefix to the additional descriptors as it does so. This allows the
descriptors for a portion of a payload to be created once and then
reused, irrespective of where in the payload the portion appears.
Closes gh-221
Previously, a LinkDescriptor had to be created with both a rel and a
description. If a description was not provided a failure would occur.
This commit relaxes the above-described restriction by allowing a
link's title to be used as its default description. If a descriptor
has a description, it will always be used irrespective of whether or
not the link has a title. If the descriptor does not have a
description and the link does have a title, the link's title will be
used. If the descriptor does not have a description and the link does
not have a title a failure will occur.
Closes gh-105
This commit updates all of the Snippet implementations that take one
or more descriptors to provide an and method that can be used to
create a new Snippet that has additional descriptors.
Closes gh-168
Previously the phase was documented as `package` by default with
instructions to change it to `prepare-package` if you want to
include the documentation in the project's package. This led to some
confusion and sometimes the step to change it to `prepare-package`
was missed.
This commit updates the documentation to recommend that
`prepare-package` is always used. It works equally well for both
cases (packaging the documentation or not) and avoids the possible
confusion described above.
Closes gh-218
This commit polishes the HTTPie request snippet contribution made in
b26d8c0. It makes the following significant changes:
- Applies project’s coding conventions for formatting and the like
- Moves to a composition-based approach for sharing functionality
between the curl and HTTPie snippets by replacing AbstractCliSnippet
with CliOperationRequest.
- Introduces a single package for CLI command snippets, thereby allowing
more code to be package-private.
See gh-207
In 1.0, the reliance on JUnit was more widespread than it should have
been. It should have been isolated to the JUnit TestRule implementation,
RestDocumentation. Unfortunately, RestDocumentation was also an argument
to MockMvcRestDocumentation.documentationConfiguration which made it
impossible to use Spring REST Docs without having JUnit on the
classpath.
This commit introduces JUnitRestDocumentation and
ManualRestDocumentation. The format is a direct replacement for
RestDocumentation which has been reworked to delegate to
JUnitRestDocumentation. The latter allows manual management of the
RestDocumentationContext, primarily for use with TestNG.
A new interface, RestDocumentationContextProvider, has been introduced.
It is implemented by RestDocumentation, JUnitRestDocumentation and
ManualRestDocumentation.
MockMvcRestDocumentation.documentationConfiguration has been overridden
to also accept a RestDocumentationContextProvider. The method that
accepts a RestDocumentation has been deprecated, as has
RestDocumentation itself.
The documentation has been updated to encourage the use of
JUnitRestDocumentation and a sample illustrating the use of Spring REST
Docs with TestNG has been added.
Closes gh-171
Previously, custom snippet templates were loaded from
org/springframework/restdocs/templates and the default templates were
loaded from org/springframework/restdocs/templates/{$formatId}.
Without relying on the ordering of the classpath, this made it
impossible to provide a custom template for a specific format.
This commit updates the locations that are checked for snippet
templates. The following locations are now checked in order:
1. org/springframework/restdocs/templates/${formatId}/${name}.snippet
2. org/springframework/restdocs/templates/${name}.snippet
3. org/springframework/restdocs/templates/${formatId}/default-${name}.snippet
The second location is provided largely for backwards compatibility
with 1.0. Users are expected to use the first location to provide
any custom templates, with Spring REST Docs provided templates for
all of the built-in snippets in the third location.
Closes gh-196
Closes gh-197
A new preprocessor method `removeMatchingHeaders` has been introduced
which takes one or more regular expression patterns (as Strings). Any
header that matches a pattern is removed.
Closes gh-195
This commit introduces support for generating snippets formatted
using Markdown. Asciidoctor remains the default.
A new SnippetFormat abstraction has been introduced with Asciidoctor
and Markdown implementations provided out of the box.
Markdown-formatted templates are also provided for all of the default
snippets.
Please refer to the updated reference documentation for further
details.
Closes gh-150
Closes gh-19
This commit adds a new module, spring-restdocs-restassured, that
can be used to generate documentation snippets when testing a service
with REST Assured.
Please refer to the updated reference documentation for details.
Thanks to Johan Haleby for making a change to REST Assured so that
path parameters could be documented.
Closes gh-102
This commit adds an Asciidoctor extension that post-processes code
blocks, collapsing any secondary blocks into the preceding primary
block. The primary block is then augmented with a switch. This switch
contains one item for each block. Clicking an item causes the associated
block’s content to be displayed. Each item is named using its block’s
title.
The getting started instructions have been updated to take advantage of
this new switching support, with the Maven and Gradle instructions
being collapsed into a single section.
Closes gh-189
The main changes are:
- Update javadoc to align with changes made in 5a01016
- Update documentation with details of the new support for documenting
HTTP headers
- Add tests to verify that HTTP headers are matched case-insensitively
Closes gh-71
Previously, the Host header was treated specially in the HTTP request
snippet. If no Host header was specified, one would always be added
prior to producing the snippet. This ensured that the snippet was
valid (an HTTP 1.1 request must include a Host header), but came at
the cost of some confusion about why a preprocessor could not remove
it.
This commit updates the special treatment of the Host header so that
it's now performed in a central location so that all of the snippets
can benefit from a Host header being added if one isn't provided.
The handling of the Content-Length header has also been reworked so
that it's performed in the same location. The curl request snippet
has been updated so that it doesn't include setting the Host header
on the command line; it's unnecessary as curl will automatically
include a Host header in the request. The documentation of the
Host header's special treatment (made in 2fc0420) that noted that it
was unaffected by preprocessing has been reverted.
Closes gh-134
For an HTTP 1.1 request to be valid it must contain a Host header. To
ensure that the HTTP request snippet is a valid HTTP 1.1 request a
Host header will always be included. If one is not present in the
request that’s being documented, the snippet will generate one
automatically. A side-effect of this is that a preprocessor that removes
the Host header will have no effect on the HTTP request snippet. This
commit updates the documentation to describe this behaviour.
Closes gh-134
Previously, only dot notation JSON field paths were supported. Using
dot notation, each key is separated by a '.'. This makes it impossible
to reference a field where the key itself contains a dot.
This commit adds basic bracket notation support to JsonFieldPath.
With this commit, existing functionality remains as is, but users can
now use a basic form of JsonPath bracket notation. This enables the
use of Json keys with embedded dots. i.e. something like :
{
"a.b" : "one"
}
.andDo(document("example",responseFields(fieldWithPath("['a.b']")…
Closes gh-132
This commit adds support for three new placeholders that can be used
when specifying the name of an operation: {ClassName}, {class-name},
and {class_name}. This allows the operation name to be configured once
in an abstract superclass and reused across multiple test classes.
Closes gh-116
Following the reworking of the API, it was no longer possible to
apply preprocessing to every test and to still customize the snippets
used by that test.
This commit adds a new snippets() method to
RestDocumentationResultHandler that allows additional snippets to be
configured once the result handler has been created. The documentation
has been updated to describe how to apply preprocessing to every
test and Spring HATEOAS sample has been updated to illustrate the
approach.
Closes gh-88
This commit splits Spring REST Docs into two projects –
spring-restdocs-core and spring-restdocs-mockmvc.
spring-restdocs-core contains the vast majority of the code but does not
depend on a specific test framework other than JUnit. The use of a
Spring Test TestExecutionListener has been replaced with a JUnit test
rule. The rule is declared once per test class and configured with
the output directory to which the generated snippets should be written.
This simplifies the implementation as thread local storage is no longer
required to transfer information about the test that’s running into
Spring REST Docs. Instead, this transfer is now handled by the new test
rule. It has also simplified the configuration as it’s no longer
necessary for users to provide a system property that configures the
output directory.
spring-restdocs-mockmvc contains code that’s specific to using Spring
REST Docs with Spring MVC Test’s MockMvc. This is currently the only
testing framework that’s supported, but it paves the way for adding
support for additional frameworks. REST Assured is one that users seem
particularly interested in (see gh-80 and gh-102).
Closes gh-107
