imagebuilder service endpoints are missing from endpoints.json in specs file

[mitkama]

Acknowledgements

• I have searched (https://github.com/aws/aws-sdk/issues?q=is%3Aissue) for past instances of this issue
• I have verified all of my SDK modules are up-to-date (you can perform a bulk update with go get -u github.com/aws/aws-sdk-go-v2/...)

Describe the bug

"imagebuilder" service endpoints are missing from endpoints.json in the specs file.

https://github.com/aws/aws-sdk-go-v2/blob/main/codegen/smithy-aws-go-codegen/src/main/resources/software/amazon/smithy/aws/go/codegen/endpoints.json

Expected Behavior

"imagebuilder" service endpoints should be present in endpoints.json.

https://github.com/aws/aws-sdk-go-v2/blob/main/codegen/smithy-aws-go-codegen/src/main/resources/software/amazon/smithy/aws/go/codegen/endpoints.json

Current Behavior

"imagebuilder" service endpoints are missing from endpoints.json in the specs file.

https://github.com/aws/aws-sdk-go-v2/blob/main/codegen/smithy-aws-go-codegen/src/main/resources/software/amazon/smithy/aws/go/codegen/endpoints.json

Reproduction Steps

"imagebuilder" service endpoints are missing from endpoints.json in the specs file

https://github.com/aws/aws-sdk-go-v2/blob/main/codegen/smithy-aws-go-codegen/src/main/resources/software/amazon/smithy/aws/go/codegen/endpoints.json

Possible Solution

add "imagebuilder" service endpoints to endpoints.json

https://github.com/aws/aws-sdk-go-v2/blob/main/codegen/smithy-aws-go-codegen/src/main/resources/software/amazon/smithy/aws/go/codegen/endpoints.json

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

go version go1.22.3 darwin/arm64

Compiler and Version used

go version go1.22.3 darwin/arm64

Operating System and version

MacOS , Sonoma 14.5

[lucix-aws]

This isn't a defect - service-specific entries in this table are only needed for specifying non-standard endpoint schemes for the partition. The Imagebuilder endpoint scheme is the default, therefore it has no entries.

Note this endpoints.json resource is also no longer used by default - EndpointResolverV2 uses a separate rules "syntax" that lives in each service's API model (though the underlying dataset is related).

[github-actions[bot]]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[mitkama]

@lucix-aws

I have few questions , it would be really great if you are able to answer these questions.

1. Can I assume, if the entry is missing in endpoints.json, in that case, the endpoint schemes will be standard as

   https://{servicename}.{region}.amazonaws.com

   Is it applicable across all AWS services ?

2. Will it be a good practice to look up entries from endpoints.json for AWS services and if the entry is not found consider the endpoint as a standard schema endpoint?
   ["https://{servicename}.{region}.amazonaws.com]

[lucix-aws]

1. No - the newer rules used by EndpointResolverV2 are the source of truth here. Older services like s3 have data in endpoints.json, but have complex endpoint rules (for virtual hosting etc.) that invalidate the endpoints.json table to some degree. Newer services, like neptunegraph, launched with endpoint rules, have totally custom/non-standard endpoints, the endpoints.json table for that service is either going to have meaningless entries or be empty.
2. No. You should NOT be looking at or caring about endpoint information for a service, at all (either in endpoints.json or the rules). The datasets for both of these are internal (within SDK code) on purpose. The service user isn't meant to know or care about routing information, you should just be setting your region and calling operations and we should be figuring it out.

Broadly speaking, I would ask why you're looking into this. It shouldn't matter for you in terms of actually using the SDKs.

[mitkama]

Thanks a lot @lucix-aws for the detailed explanation. I need a few more details from you, please go through the below para and let me know your thoughts.

We would like to have this information for the following reasons.

The system that we are building reads a template file, The template file has details related to the AWS service name and operation [api] name. We load smithy specs and endpoints.json file and we dynamically form HTTP Requests for AWS services based on service name and operation name and details from smithy specs and endpoints.json.

If the endpoints.json is not correctly maintained in this repo, we won't be able to form the correct endpoint for all the AWS services and hence the system won't work as expected.

What will be your suggestion to load the correct endpoints of all AWS services from smithy models?

[lucix-aws]

My suggestion to you is frankly that your approach is a complete nonstarter. Abandon any notion of what you're trying to do here, because it's more than likely doomed to fail and is in no way supported.

1. The smithy models you're trying to load are completely internal. They're only used to generate the service clients which make up the Go V2 SDK.
2. The endpoints.json table, as previously stated, is completely internal.

We can't guarantee that these resources will even exist in this repository long-term, or that the formats and data therein are stable whatsoever.

The system that we are building reads a template file, The template file has details related to the AWS service name and operation [api] name. We load smithy specs and endpoints.json file and we dynamically form HTTP Requests for AWS services based on service name and operation name and details from smithy specs and endpoints.json.

You're going about this the wrong way. I can't solve this problem for you, but I understand the "dynamic" nature of what you're trying to do with this template. Loading service models and mapping them to requests is just not the right way to do it, at all. It sounds like you'd need to map these requests to actual concrete calls to service clients in the V2 SDK. That's going to be incredibly verbose, but if those are the business requirements, it's the only thing I can direct you to do.

If you proceed with your current approach, you do so entirely at your own risk (but seriously, don't).

[mitkama]

Thanks @lucix-aws for your detailed response and suggestions.

Does AWS have any OpenAPI specs alternative to achieve this requirement instead of relying on smithy specs?

[lucix-aws]

No. There are no public representations of the data you're trying to work off of whatsoever.