Comments (7)
Interesting suggestion. Thanks. I'm less opposed to reusing existing annotations, such as those for bean validation, than I am to adding annotations to your implementation specifically for the purposes of documentation.
I want to keep Spring REST docs as "stupid" as possible. I don't want it to try to discover your DTOs and exactly how they're validated as it'll inevitably get it wrong on occasion, lag behind validation features in the framework, etc. An explicit API that, for example, takes a class and a field name and extracts a description of the bean validation constraints would (largely) avoid these problems. I think it certainly warrants some exploration, particularly if others are interested in this functionality. +1s welcome.
from spring-restdocs.
👍
from spring-restdocs.
👍
from spring-restdocs.
👍
from spring-restdocs.
The fact that this is possible with the Bean Validation API makes me doubt the wisdom of trying to implement this.
from spring-restdocs.
@wilkinsona ouch! I do take your point. For sure libraries and languages can often be abused in interesting and sometimes unbelievable ways ;)
This suggestion really grew out of a desire to find a good way to document request body constraints in a way that is; easy for someone to understand, doesn't bloat the documentation too much and doesn't require developers to duplicate descriptions of declarative rules.
Sure, I can write tests that violate lots of different rules ( and if my response body conatins more descriptive messages that just "400 bad request", this will ensure that a meaningful response body ends up in the documentation), but as I pointed out above, I don't feel like this is good way for people to consume this data...
In my precise use-case JSON is the interchange format of choice, so I know there are solutions out there that might help document things like the schema. Some of these also support things like required and min/max lengths and so on. But, again these require additional annotations.
It'd be great to find a solution that can document the request body and the basic constraints without resorting to duplicating annotations or adding new ones just for the purpose of documentation. I understand not everyone will use bean-validation but, to me at least, supporting these seems like a fair idea since a standard library exists. I'd be keen to hear other ideas about the best way of doing this and thanks again for taking the time to read and consider this suggestion.
from spring-restdocs.
I like this idea very much and supporting a subset of the existing annotations (like Notnull, Regexp, Min, Max, Length ..) should work for 99% of the users.
from spring-restdocs.
Related Issues (20)
- Avoid substring creation when writing a portion of a string to a StringBuilder
- How to hide Request Body and curl particular fields like "Token"? while generating spring rest docs through rest assured approach HOT 1
- Request-body.adoc is coming as blank in case of get call HOT 3
- Except body fields how can I add others mandate fields like headers(correlationId, destination, srDate) HOT 1
- Getting issue related to query parameter. HOT 5
- Latest dependencies issue is coming while generating rest docs HOT 2
- Any concern that the underlying asciidoc gradle plugin doesn't work with Java 17 or 21? HOT 1
- Upgrade Gradle Enterprise Plugins
- Using JWT Token to Access Resource Server HOT 2
- Cannot document form parameters when using Rest Assured's MockMvc support when contentType is multipart/form-data HOT 5
- Upgrade to Gradle Enterprise Conventions 0.0.16
- Move to GitHub Actions to build and deploy snapshots
- Run Windows and Java compatibility builds on GitHub Actions
- Document that the query string should be provided in the URL or by using queryParam when using MockMvc HOT 1
- JavaDoc support HOT 1
- Upgrade to Gradle Enterprise Conventions 0.0.17
- Issue with the Junit Rest Documentation with the spring docs 2.0.5.Release and spring boot version 2.7.6 version in controller testcases HOT 2
- Facing issue with asciidoctor.jvm.convert 2.4.0 and spring docs 2.0.5 release Which is unable to load the child.html in the index html HOT 2
- Facing issue with asciidoctor.jvm.convert 2.4.0 and spring docs 2.0.5 release while creating war using gradle 8.6 the public/docs folder is not getting created HOT 3
- Improve usage documentation for markdown HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spring-restdocs.