Feature idea: generate query from @httpRequestTests

[kubukoz]

An operation in Smithy can be annotated with the httpRequestTests trait, which contains a list of example requests.

We could offer the ability to generate an operation's input based on examples from that trait.

For example:

$version: "2"

namespace smithy4s.example

use smithy.test#httpRequestTests
use smithy4s.api#simpleRestJson

@simpleRestJson
service HelloService {
    operations:[TestPath]
}

@http(method: "GET", uri: "/test-path/{path}")
@readonly
@httpRequestTests([
    {
        id: "TestPath",
        protocol: simpleRestJson,
        method: "GET",
        uri: "/test-path/sameValue"
        params: { path: "sameValue" }
    }
])
operation TestPath {
    input := {
        @httpLabel
        @required
        path: String
    }
}

If the user writes:

use service smithy4s.example#HelloService

TestPath {
  <cursor>
}

the file is in a parseable state, and the position of the cursor is known. At the time of writing, Playground will generate the completions for the field:

it would be convenient to provide an additional completion item for each of the @httpREquestTests entries, which upon accepting would overwrite the entire input of the operation.

[kubukoz]

Implementation-wise, this would require inspecting the smithy.test.HttpRequestTests trait inside CompletionProvider (I don't think that trait is available, so we might need to add some dependencies to handle that).

The completions could be eagerly loaded when building the provider, and added to the result of finding completions in this case:

case NodeContext.PathEntry.AtOperationInput ^^: ctx =>
  serviceIdOpt match {
    case Some(serviceId) =>
      completionsByEndpoint(serviceId)(
        q.operationName.value.operationName.value.mapK(WithSource.unwrap)
      )
        .getCompletions(ctx)

    case None => Nil
  }

if and only if ctx matches StructBody ^^: Empty.

There should be a textual hint saying where the example input comes from.

[kubukoz]

Forgot to mention, HttpRequestTests's params is a Document. We can render a document using its NodeEncoder instance, but it'd be worth first checking if Smithy itself validates that the document is compatible with the operation's inputs. If it does, that's all good. If it doesn't, we might want to do it and show a warning sign or deprecation (?) next to the completion.