---?image=docs/assets/title.jpeg&size=contain%&position=left
---?image=docs/assets/epages.png&size=cover
@ul
- Takes a test-driven approach which guarantees accuracy
- Uses Asciidoctor by default
- Works with Spring MVC Test
@ulend
---?image=docs/assets/live-coding.jpeg&size=cover
---?image=docs/assets/towards-public-api-doc.jpg&size=cover
Note:
- different challenges
- bring tech writers in
- Tech writers should not have to edit descriptions in tests
.andDo(document("product-get",
responseFields(
fieldWithPath("name")
.description("The name of the product."),
fieldWithPath("price")
.description("The price of the product.")
)
));
Note:
- Use externalized descriptors.
.andDo(document("cart-create-payment",
requestFields(
fieldWithPath("returnUri", "createPayment.returnUri"),
fieldWithPath("cancelUri", "createPayment.cancelUri")),
responseFields(
fieldWithPath("approvalUri", "createPayment.approvalUri"))));
createPayment.returnUri:
description: The redirect URI after successful payment authorization.
createPayment.cancelUri:
description: The redirect URI if the payment authorization was not successful.
createPayment.approvalUri:
description: The URI used to approve the payment. The client has to redirect to this URI to initiate the approval.
- In documenting tests, we use a test data catalog defined by TechWriting
- One repository that composes all public documentation from the relevant microservices
Note:
- each service emits documentation
- how can we aggregate this into a single consistent api documentation which is always up-to-date
Note:
- on master build emit a separate jar containing snippets and hand-written documentation from each service
- aggregate the jars relevant for public api doc in the cdp
- for asciidoc there is an enclosing assiidoctor file referencing parts from the jar
- publish api doc
---?image=docs/assets/achievements.jpg
- Static API documentation available on our developer portal
- Good starting point to work with partners
---?image=docs/assets/more.jpg&size=auto
Note:
- We need to add use case based documentation
- API docs should be a nice appetizer to start using our product
- We cannot achieve this with a static documentation
- We need to go interactive!
@ul
- AsciiDoc as a markup language is hard to process
- It is hard to get any further than static HTML
- A machine readable format is what we need
@ulend
---?image=docs/assets/raml.png&size=cover
#%RAML 1.0
title: Hello world # required title
/greeting: # optional resource
get: # HTTP method declaration
responses: # declare a response
200: # HTTP status code
body: # declare content of response
application/json: # media type
# structural definition of a response (schema or type)
type: object
properties:
message: string
example: # example how a response looks like
message: "Hello world"
We built @fa[github] restdocs-raml
- To keep the benefits of Spring REST Docs
- To get a RAML description of our API
---?image=docs/assets/restdocs-raml-repo.png&size=cover
---?image=docs/assets/live-coding.jpeg
@ul
- Adding restdocs-raml to an existing project is easy
- A RAML representation of an API opens a lot of new possibilities
- Leverage the tools available in the RAML ecosystem
@ulend
@fa[eye] Slides
https://gitpitch.com/mduesterhoeft/spring-restdocs-raml-talk
@fa[github] Sample project
https://github.com/mduesterhoeft/spring-restdocs-raml-talk
@fa[github] restdocs-raml
https://github.com/ePages-de/restdocs-raml
Questions?
@fa[twitter] @zaddo
@fa[twitter] @epagesdevs
@fa[comments] https://gitter.im/restdocs-raml/restdocs-raml