Various client APIs you provide have request structs that reference your types package. This renders all of these structs unusable as they cannot be imported outside of your module.
Use of internal should be strictly limited for internal implementation that is never exposed to end users. While moving it out of the internal package is one solution, having a package named types is also very broad and nonspecific.
Ideally a better designed Go SDK structure would organize your entire SDK into a single flat package (there isn't really a use to having a sub package for each group of your api endpoints). Another option would be to move it to a separate package like, bp.
edit: I see that these constants are exposed in the blindpay package directly, however this still makes your API usage relatively poor, e.g. you can't pass a constant as any function you own, since the type is still within the internal package.
Various client APIs you provide have request structs that reference your
typespackage. This renders all of these structs unusable as they cannot be imported outside of your module.Use of
internalshould be strictly limited for internal implementation that is never exposed to end users. While moving it out of the internal package is one solution, having a package namedtypesis also very broad and nonspecific.Ideally a better designed Go SDK structure would organize your entire SDK into a single flat package (there isn't really a use to having a sub package for each group of your api endpoints). Another option would be to move it to a separate package like,
bp.edit: I see that these constants are exposed in the
blindpaypackage directly, however this still makes your API usage relatively poor, e.g. you can't pass a constant as any function you own, since the type is still within theinternalpackage.