AJR/TechradarDev
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix typos and change some grammatical constructions

Browse Source
This commit is contained in:
daniel.motzko
2021-07-02 10:31:14 +02:00
parent 28005ee0b6
commit 8bfcbe8ae7
6 changed files with 13 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
radar/2017-03-01/api-first-design-approach.md
View File

@@ -9,7 +9,7 @@ The API-First Design Approach puts the API design at the beginning of the implem
There are several advantages to this approach. For example, it can help to avoid reflecting the internal structure of the application or any internal constraints. Furthermore, as one of the most important design aspects is consistency, one can define features such as the behavior of security, URL schemes, and API keys upfront. It also helps speed up parallel implementation. A team that consumes the API can start working directly after the API design because it can easily be mocked.
There are several tools for modelling an API, but here at AOE we mainly use [RAML](/tools/raml.html) as it provides a rich set of tools for generating documentation, mocking and more. For mocking we use [Wiremock](/tools/wiremock.html), for example.
There are several tools for modelling an API, but here at AOE we mainly use [RAML](/tools/raml.html) as it provides a rich set of tools for generating documentation, mocking and more. For mocking we use [WireMock](/tools/wiremock.html), for example.
Related to the "API-First" approach is the "Headless" approach where an existing application (with or without existing API) is used as a backend for a separate frontend. We used this with sucess for Magento-based E-Commerce platforms. This allows encapsulating the core features of that application, while integrating it into a larger landscape of components using its API as a unified way to interact between components. Decoupling the core logic from its presentation layer allows picking the best technology stack for the various parts independently.

2
radar/2017-03-01/spring-rest-docs.md
View File

@@ -6,4 +6,4 @@ quadrant: tools
---
[Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured.html). So you can be sure that your tests are inline with the documentation.
At AOE, we use [Spring REST Docs](https://projects.spring.io/spring-restdocs/) to document our Rest Services and Hal Resources. We also use it to auto generate [Wiremock](/tools/wiremock.html) Stubs, so the consumer of the service can test against the exact API of the service.
At AOE, we use [Spring REST Docs](https://projects.spring.io/spring-restdocs/) to document our Rest Services and Hal Resources. We also use it to auto generate [WireMock](/tools/wiremock.html) Stubs, so the consumer of the service can test against the exact API of the service.

2
radar/2017-03-01/wiremock.md
View File

@@ -1,5 +1,5 @@
---
title: "Wiremock"
title: "WireMock"
ring: trial
quadrant: tools