The Functional toolkit for Kotlin HTTP applications. http4k provides a simple and uniform way to serve, consume, and test HTTP services.

Are there plans to support coroutines in http4k?

Specifically, would be great to see an enhanced HttpAsyncClient interface and implementations that offer a suspend function to be used in place of the current invoke with callback. I've prototyped this and seems to work well.

On the http server side, it would be nice to see route support that would allow async responses to be provided. Currently routes are called on the netty worker thread - and if those threads block on IO or otherwise take a long time to complete, then worker threads are unavailable to service other requests. Ideally there would be a coroutine friendly way of specifying routes - allowing the worker thread to go back to its business of dispatching work while leaving the drudgery of creating the response up to coroutines and the threads in their associated contexts. Haven't prototyped this yet - but worming my way through http4k code and have an idea of where this might work.

The Etag filter was previously broken, using the response from toString to generate the hash.

An attempt to fix this was pushed in commit: 4f1491f5ad2cdd09b1e7a8d94ab97d3f581966bf

A subsequent commit simplified the code (but left it still in a broken state): 5a8d989859bfa4e863b4adc534dbea967474387d - reading the byte array in this way moves the pointer and results in the HTTP response containing a valid Etag, but a 0 length payload!

Structured logging is useful for a number of reasons. It makes it easier to parse logs using a tool that understands either key=value or json structures.

Allow configuring the output format for easier integration with tools like Stackdriver.

I've checked the techempower benchmarks and it seems that http4k-netty performs really badly and has a lot of errors in the benchmarks. Is this an inherent problem with Netty or is the benchmark bad?

According to https://github.com/http4k/http4k/issues/118 That's what I came up with - a draft implementation of latency injection filter

I also added header setting, so one can understand whether the request is slow because of chaos injection or some other reasons

cc @daviddenton

Some of the docs currently look like this:

One has to use horizontal scrolling to see the whole code (Firefox, MBP 2019, no zoom)

Suggestion: Applying max_line_length = 80 for all Kotlin files in src/docs, so everything fits on the screen without scrolling.

Searched around for this and it seems like this was already a thing in the slack channel, but seems like the PR was never opened(?).

This is a follow up MR for https://github.com/http4k/http4k/pull/564, please review by individual commits.

Based on @daviddenton's suggestion for FieldMetadataRetrieval, I refactored the previous code. Probably the only remaining issue is flattening the SchemaNode.extra so that its contents become directly part of the SchemaNode.

Now the resulting node looks like:

"bio": {
   "example": "Bar",
   "description": null,
   "extra": {
        "minLength": 0,
        "maxLength": 512
    },
    "type": "string"
},

but to be compliant, it should look like:

"bio": {
   "example": "Bar",
   "description": null,
   "minLength": 0,
   "maxLength": 512,
   "type": "string"
},

CC @goodhoko

Following the discussion in #287 , I've gone ahead and used the RequestContexts mechanism to expose the underlying AWS Lambda context object, as well as the request object, so that lambdas using http4k have full access to the metadata and tools that AWS Lambda sends along on every invocation.

I've also did a few tweaks to fix Java 8 support, as I'm still stuck on it :(

One important detail is that for backwards-compatibility I did not change the existing AppLoader interface, but added AppLoaderWithContexts. This way, existing users of the serverless module will not suddenly see compilation errors upon updating.

See the individual commit messages for more details.

I went a bit beyond what was discussed in #287 and also pulled in the aws-lambda-java-events library -- my reasoning is documented in the commit message of 5abbd75:

The format of the input message for a lambda is documented in https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format and several of these fields were missing from the previous ApiGatewayProxyRequest/ApiGatewayProxyResponse.

This means that in particular, fields such as the requestContext, and stageVariables, as well as multi-value headers and parameters were unavailable.

Rather than manually adding each of the missing fields (and its nested fields) to the proxy request/response classes, instead I went ahead and added a dependency on the small (around 100kb as of this writing -- https://mvnrepository.com/artifact/com.amazonaws/aws-lambda-java-events/2.2.7) aws-lambda-java-events library, which already includes POJOs for all of the fields and their nested objects.

Fixes #287

This replaces the default Apache client & server modules with version 5 of the client & core.

The version 4 client/server is retained in the *-apache4 modules.

Note that the v5 async client only supports in-memory bodies at present, due to changes in the API. Streaming support with take a bit more reworking, if desired.

As touched on in the "Server as a Function. In Kotlin" presentation, it would be awesome to have a separate module which introduced bad behaviour to http4k applications.

This could be easily modelled by a set of filters which generated the chaos behaviours in http4k apps.

Inspired by this: https://codecentric.github.io/chaos-monkey-spring-boot/

I'm using the contracts library to generate Swagger definitions for my API, and then using swagger-code-gen to generate client libraries in different languages. Currently, the Swagger model definitions from Http4k look like:

"definitions" : {
  "object-1918755743" : {
    "type" : "object",
    "properties" : {
      "reason" : {
        "type" : "string"
      }
    }
   },
  "object1265469862" : {
    "type" : "object",
    "properties" : {
      "id" : {
        "type" : "integer"
      },
      "title" : {
        "type" : "string"
      }
    }
  }
}

Instead, I'd like to give these models a name, so they're named correctly in our generated Python library as well in our Swagger UI docs.

KotlinxSerialization.asFormatString seems incapable of properly handling polymorphic types; it fails to properly serialize the type parameter. I believe this works with raw kotlinx and with lenses because they both reifiy the base provided type, rather than rely on the runtime type.

I don't really see a way around this short of extensive modifications to asFormatString to reify the type. However, doing so would also allow the http4k-format-csv module to become an AutoMarshalling, as this was a limiting issue.

Thoughts? Live with and document the limitation? Or try to reify the type in asFormatString?

See the provided tests below, where serialize sealed class - http4k asFormatString fails.

@Serializable
sealed interface Animal {
    val name: String
}

@Serializable
@SerialName("cat")
data class Cat(
    override val name: String,
    val lives: Int,
): Animal

val json = """{"type":"cat","name":"Bandit","lives":8}"""
val obj = Cat("Bandit", 8)
val lens = KotlinxSerialization.autoBody<Animal>().toLens()

@Test
fun `serialize sealed class - kotlinx encodeToString`() {
    assertThat(
        Json.encodeToString(obj as Animal),
        equalTo(json)
    )
}
// PASS

@Test
fun `serialize sealed class - http4k asFormatString`() {
    assertThat(
        KotlinxSerialization.asFormatString(obj as Animal),
        equalTo("""{"type":"cat","name":"Bandit","lives":8}""")
    )
} // FAIL.  Was {"name":"Bandit","lives":8}"

@Test
fun `serialize sealed class - http4k lens`() {
    assertThat(
        Response(Status.OK).with(lens of obj).bodyString(),
        equalTo(json)
    )
}
// PASS

@Test
fun `deserialize sealed class - kotlinx decodeFromString`() {
    assertThat(
        Json.decodeFromString<Animal>(json),
        equalTo(obj)
    )
}
// PASS

@Test
fun `deserialize sealed class - http4k asA`() {
    assertThat(
        KotlinxSerialization.asA<Animal>(json),
        equalTo(obj)
    )
}
// PASS

@Test
fun `deserialize sealed class - http4k lens`() {
    assertThat(
        lens(Response(Status.OK).body(json)),
        equalTo(obj)
    )
}
// PASS

Hello there ! I'm struggling to understand what would be the best way to add the audience form field from auth0 on the AccessTokenFetcher. From what I understand auth0 sends back an opaque token by default unless you provide an audience parameter to the token endpoint (cf https://community.auth0.com/t/why-is-my-access-token-not-a-jwt-opaque-token/31028) If I'm correct this parameter should be added in the AccesTokenFetcher fetch method but as the requestForm is implemented as https://github.com/http4k/http4k/blob/master/http4k-security/oauth/src/main/kotlin/org/http4k/security/OAuthWebForms.kt#L15-L24 I'm not sure if it is possible to add the parameter without rewriting the whole thing. The workaround would be to hit the /userinfo endpoint with the opaque token but I was wondering if these kind of settings would belong into this library or if it is out of scope. https://github.com/http4k/http4k/blob/master/http4k-security/oauth/src/main/kotlin/org/http4k/security/AccessTokenFetcher.kt#L34-L37

In any way thanks for the time and thanks for the awesome work it really is a pleasure working with http4k

Currently MultipartFormField.string().json() renders in the openapi spec as a type: string without any further context (even if you map the JsonObject). mapWithNewMeta + ParamMeta.Object renders it as an object, but again with no information about the shape of the object.

I would like to be able to map a MultipartFormField and render the object in the schema with all of it's feilds. This is supported by the openapi spec and they even declare the default content type for these multipart object fields is application/json.

I would like this as I transfer a lot of files (and cannot take the base64 overhead and use json) as well as use codegen to generate a client to consume my API.

I would be more than happy to implement this myself. I would like to know if it's feasible and if so - some pointers on where to begin.

I'm not wedded to the implementation, especially the nasty self-type extension functions (well I'm secretly proud of them, but happy to see them replaced if you have a better way), but interested in feedback on the interface.

In particular - Map<Any, Any> feels like it shuts least doors, but Map<String, Any> may communicate better, and if people really need a map with arbitrary keys they can add their own to the userData map?

This Pull Request proposes small improvements to the build script logic to improve performance and maintainability.

Changes:

• Remove openapi-generator-gradle-plugin
• Migrate http4k-contract build script to Kotlin DSL to be consistent with the rest of the modules

I was looking at the configuration of org.openapitools.generator.gradle.plugin.tasks.GenerateTask tasks. The way they are configured makes them not cacheable https://scans.gradle.com/s/cnwrkzmkwogak/timeline?cacheability=overlapping_outputs. They write the output into the same directory, therefore gradle is not able to infer the cacheability of these tasks. Also, the output folder is actually located outside of the gradle workspace and generated files are not included in the build. Unless I'm missing something, it looks to me that these tasks can be removed from the build. Removal of tasks makes the build logic a little bit more straightforward, and faster, and requires fewer dependencies.