Release 1.2.0

README.md

@@ -128,7 +128,7 @@ tapir documentation is available at [tapir.softwaremill.com](http://tapir.softwa
 Add the following dependency:
 
 ```sbt
-"com.softwaremill.sttp.tapir" %% "tapir-core" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-core" % "1.2.0"
 ```
 
 Then, import:

generated-doc/out/client/http4s.md

@@ -3,7 +3,7 @@
 Add the dependency:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-http4s-client" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-http4s-client" % "1.2.0"
 ```
 
 To interpret an endpoint definition as an `org.http4s.Request[F]`, import:

generated-doc/out/client/play.md

@@ -3,7 +3,7 @@
 Add the dependency:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-play-client" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-play-client" % "1.2.0"
 ```
 
 To make requests using an endpoint definition using the [play client](https://github.com/playframework/play-ws), import:

generated-doc/out/client/sttp.md

@@ -3,7 +3,7 @@
 Add the dependency:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-sttp-client" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-sttp-client" % "1.2.0"
 ```
 
 To make requests using an endpoint definition using the [sttp client](https://github.com/softwaremill/sttp), import:
@@ -102,7 +102,7 @@ In this case add the following dependencies (note the [`%%%`](https://www.scala-
 instead of the usual `%%`):
 
 ```scala
-"com.softwaremill.sttp.tapir" %%% "tapir-sttp-client" % "1.1.4"
+"com.softwaremill.sttp.tapir" %%% "tapir-sttp-client" % "1.2.0"
 "io.github.cquiroz" %%% "scala-java-time" % "2.2.0" // implementations of java.time classes for Scala.JS
 ```
 

generated-doc/out/docs/asyncapi.md

@@ -3,7 +3,7 @@
 To use, add the following dependencies:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-asyncapi-docs" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-asyncapi-docs" % "1.2.0"
 "com.softwaremill.sttp.apispec" %% "asyncapi-circe-yaml" % "..." // see https://github.com/softwaremill/sttp-apispec
 ```
 

generated-doc/out/docs/openapi.md

@@ -13,7 +13,7 @@ these steps can be done separately, giving you complete control over the process
 To generate OpenAPI documentation and expose it using the Swagger UI in a single step, first add the dependency:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-swagger-ui-bundle" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-swagger-ui-bundle" % "1.2.0"
 ```
 
 Then, you can interpret a list of endpoints using `SwaggerInterpreter`. The result will be a list of file-serving 
@@ -55,7 +55,7 @@ for details.
 Similarly as above, you'll need the following dependency:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-redoc-bundle" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-redoc-bundle" % "1.2.0"
 ```
 
 And the server endpoints can be generated using the `sttp.tapir.redoc.bundle.RedocInterpreter` class.
@@ -65,7 +65,7 @@ And the server endpoints can be generated using the `sttp.tapir.redoc.bundle.Red
 To generate the docs in the OpenAPI yaml format, add the following dependencies:
 
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-openapi-docs" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-openapi-docs" % "1.2.0"
 "com.softwaremill.sttp.apispec" %% "openapi-circe-yaml" % "..." // see https://github.com/softwaremill/sttp-apispec
 ```
 
@@ -133,7 +133,7 @@ For example, generating the OpenAPI 3.1.0 YAML string can be achieved by perform
 
 Firstly add dependencies:
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-openapi-docs" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-openapi-docs" % "1.2.0"
 "com.softwaremill.sttp.apispec" %% "openapi-circe-yaml" % "..." // see https://github.com/softwaremill/sttp-apispec
 ```
 
@@ -164,12 +164,12 @@ The modules `tapir-swagger-ui` and `tapir-redoc` contain server endpoint definit
 yaml format, will expose it using the given context path. To use, add as a dependency either
 `tapir-swagger-ui`:
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-swagger-ui" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-swagger-ui" % "1.2.0"
 ```
 
 or `tapir-redoc`:
 ```scala
-"com.softwaremill.sttp.tapir" %% "tapir-redoc" % "1.1.4"
+"com.softwaremill.sttp.tapir" %% "tapir-redoc" % "1.2.0"
 ```
 
 Then, you'll need to pass the server endpoints to your server interpreter. For example, using akka-http:

generated-doc/out/endpoint/basics.md

@@ -30,7 +30,7 @@ import sttp.tapir._
 type PublicEndpoint[I, E, O, -R] = Endpoint[Unit, I, E, O, R]
 ```
 
-A public endpoint has two inputs of types `UUID` and `Int`, upon error returns a `String`, and on normal 
+A public endpoint that has two inputs of types `UUID` and `Int`, upon error returns a `String`, and on normal 
 completion returns a `User`, would have the type:
 
 
@@ -40,7 +40,7 @@ import sttp.tapir._
 val userEndpoint: PublicEndpoint[(UUID, Int), String, User, Any] = ???
 ```
 
-You can think of an endpoint as a function, which takes input parameters of type `A` and `I` and returns a result of type 
+You can think of an endpoint as a function which takes input parameters of type `A` and `I` and returns a result of type 
 `Either[E, O]`.
 
 ### Infallible endpoints
@@ -49,7 +49,7 @@ Note that the empty `endpoint` description maps no values to either error and su
 are still represented and allowed to occur. In case of the error output, the single member of the unit type, `(): Unit`, 
 maps to an empty-body `400 Bad Request`.
 
-If you prefer to use an endpoint description, where errors cannot happen, use 
+If you prefer to use an endpoint description where errors cannot happen use 
 `infallibleEndpoint: PublicEndpoint[Unit, Nothing, Unit, Any]`. This might be useful when
 interpreting endpoints [as a client](../client/sttp.md).
 

generated-doc/out/endpoint/codecs.md

@@ -29,8 +29,8 @@ integer. If any of this fails, a decode failure will be reported.
 
 However, in some cases codecs aren't looked up as implicit values, instead being created from simpler components, which
 themselves are looked up as implicits. This is the case e.g. for json bodies specified using `jsonBody`. The rationale 
-behind such a design is that this provides better error reporting, in case the implicit components, used to create the
-codec, are missing. Consult the signature of the specific input/output to learn what are its implicit requirements.
+behind such a design is that this provides better error reporting, in case the implicit components used to create the
+codec are missing. Consult the signature of the specific input/output to learn what are its implicit requirements.
 
 ## Decode failures
 

generated-doc/out/endpoint/customtypes.md

@@ -36,7 +36,7 @@ information:
 * schema (for documentation and validation)
 * codec format (`text/plain`, `application/json` etc.)
 
-This might be quite a lot of work, that's why it's usually easier to map over an existing codec. To do that, you'll 
+This might be quite a lot of work; that's why it's usually easier to map over an existing codec. To do that, you'll 
 need to provide two mappings: 
 
 * a `decode` method which decodes the lower-level type into the custom type, optionally reporting decode failures 
@@ -88,19 +88,14 @@ implicit val myIdCodec: PlainCodec[MyId] = Codec.string.mapDecode(decode)(encode
  usually better to define a codec for that type. 
 ```
 
-Then, you can use the new codec e.g. to obtain an id from a query parameter, or a path segment:
+Then, you can use the new codec; e.g. to obtain an id from a query parameter, or a path segment:
 
 ```scala
 endpoint.in(query[MyId]("myId"))
 // or
 endpoint.in(path[MyId])
 ```
 
-### Codecs for enumerations
-
-In some cases, codecs for enumerations can be derived, but need to be defined as an implicit value by hand, because
-you'll need to provide some parameters. See the section on [enumerations validators](validation.md) for more details.
-
 ## Next
 
 Read on about [deriving schemas](schemas.md).