smithy-go does not provide support for @restJson1 protocol trait about smithy-go

[jasdel]

Thanks for reaching out @jabalsad. Currently the smithy-go code generation is a basic smithy generator that does not yet have any protocol implementations. All protocol implementations are in the aws-sdk-go-v2's smithy code generation. This is one of the main reasons the smithy-go codegen has limited documentation is not published to maven central yet.

With that said, I think its reasonable to investigate moving the aws-sdk-go-v2 codegen implementation of awsRestJson1 to smithy-go as a opinionated generic REST JSON smithy protocol implementation. This most likely will require extracting/decoupling AWS specific traits, behavior, and AWS codegen utilities from the awsRestJson1 protocol implementation. This would be the first step to investigate at how tightly the awsRestJson1 protocol implementation s coupled with the AWS code generators.

The AwsRestJson1.java is the implementation of this protocol in the v2 SDK's codegen, which is basically just RestJsonProtocolGenerator. The smithy-go HttpBindingProtocolGenerator provides the bulk of the HTTP REST implementation with RestJsonProtocolGenerator defining mostly the JSON serde, and middleware.

[jabalsad]

Actually, I think this problem might be core to the issue we're facing. Besides the VSCode editor complaining that it cannot resolve the restJson1 trait, we also realize that the generated go client contains no implementation for serializing, deserializing and building the request/response cycles.

We've tried to implement these ourselves, but with no luck due to poor documentation. Any advice on how to go about solving this problem? This is a blocker for us.

[jhecking]

I managed to build the smithy-aws-go-codegen and smithy-go-codegen packages and then use them to generate client Go code for the simple weather demo model.

Unfortunately, the generated code has a few dependencies on internal packages of the AWS SDK package, e.g.

api_client.go:	internalConfig "github.com/aws/aws-sdk-go-v2/internal/configsources"
internal/endpoints/endpoints.go:	endpoints "github.com/aws/aws-sdk-go-v2/internal/endpoints/v2"

That makes the generated code pretty much unusable at the moment. On the other hand, it looks like maybe the effort required to generate code that's decoupled from the AWS SDK might not be that big?

[lucix-aws]

This is true for every aws protocol right now, moving to #458.