Giter Site home page Giter Site logo

leaseweb / leaseweb-go-sdk Goto Github PK

View Code? Open in Web Editor NEW
8.0 8.0 4.0 2.22 MB

The Golang SDK for Leaseweb API

Home Page: https://developer.leaseweb.com

License: Apache License 2.0

Shell 100.00%
go go-sdk golang leaseweb networking rest rest-api sdk

leaseweb-go-sdk's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

leaseweb-go-sdk's Issues

Metadata as a separate return value

For example for DedicatedServerApi List function, instead of returning (*DedicatedServers, error) it would be better to return ([]DedicatedServer, Metadata, error). Then it's very clear that List return a list of DedicatedServer.

It is unexpected from the name to have a DedicatedServers struct contains some metadata from the response.

Wiki pages are outdated

@tardypad As we merged the #74 PR, the wiki pages and README file are outdated! so I'll create this issue to update the docs!
I would appreciate if you can find a way to generate docs automatically!

Support OAuth

Currently, we can only connect to leaseweb API by setting x-lsw-auth in header. We need to connect to leaseweb API using OAuth as well.

Inconsistent Handling of Input Arguments in List Function

we noticed that the DedicatedServerApi List function in the provided code is inconsistently handling its input arguments. Specifically, the function accepts multiple arguments of different types and lengths, but it does not provide any clear guidelines on how to use these arguments, and it does not handle them consistently.

To address this issue, I suggest using a struct to store the input options for the List function, as shown in the provided code workaround. This approach provides a more structured and flexible way of handling input options and avoids the issues of inconsistently handling input arguments.

I believe this change will improve the clarity and maintainability of the code and make it easier for developers to use the List function. I welcome any feedback or suggestions on this approach and would appreciate it if the project maintainers could review and consider this change.

Thank you.

+type ListOptions struct {
+	Offset                int
+	Limit                 int
+	IP                    string
+	MacAddress            string
+	Site                  string
+	PrivateRackID         string
+	PrivateNetworkCapable bool
+	PrivateNetworkEnabled bool
+}
+
 func (dsa DedicatedServerApi) getPath(endpoint string) string {
 	return "/bareMetals/" + DEDICATED_SERVER_API_VERSION + endpoint
 }
 
-func (dsa DedicatedServerApi) List(args ...interface{}) (*DedicatedServers, error) {
+func (dsa DedicatedServerApi) List(opts ...ListOptions) (*DedicatedServers, error) {
 	v := url.Values{}
-	if len(args) >= 1 {
-		v.Add("offset", fmt.Sprint(args[0]))
-	}
-	if len(args) >= 2 {
-		v.Add("limit", fmt.Sprint(args[1]))
-	}
-	if len(args) >= 3 {
-		v.Add("ip", fmt.Sprint(args[2]))
-	}
-	if len(args) >= 4 {
-		v.Add("macAddress", fmt.Sprint(args[3]))
-	}
-	if len(args) >= 5 {
-		v.Add("site", fmt.Sprint(args[4]))
-	}
-	if len(args) >= 6 {
-		v.Add("privateRackId", fmt.Sprint(args[5]))
-	}
-	if len(args) >= 7 {
-		v.Add("privateNetworkCapable", fmt.Sprint(args[6]))
-	}
-	if len(args) >= 8 {
-		v.Add("privateNetworkEnabled", fmt.Sprint(args[7]))
+	if len(opts) > 0 {
+		opt := opts[0]
+		if opt.Offset > 0 {
+			v.Add("offset", fmt.Sprint(opt.Offset))
+		}
+		if opt.Limit > 0 {
+			v.Add("limit", fmt.Sprint(opt.Limit))
+		}
+		if opt.IP != "" {
+			v.Add("ip", opt.IP)
+		}
+		if opt.MacAddress != "" {
+			v.Add("macAddress", opt.MacAddress)
+		}
+		if opt.Site != "" {
+			v.Add("site", opt.Site)
+		}
+		if opt.PrivateRackID != "" {
+			v.Add("privateRackId", opt.PrivateRackID)
+		}
+		if opt.PrivateNetworkCapable {
+			v.Add("privateNetworkCapable", "true")
+		}
+		if opt.PrivateNetworkEnabled {
+			v.Add("privateNetworkEnabled", "true")
+		}
 	}

Private networking documentation

We need to have documentation for the private networking, I would suggest keeping the documentation in the current repo in Wiki section.

Customer Account documentation

We need to have documentation for the customer account, I would suggest keeping the documentation in the current repo in Wiki section.

Abuse documentation

We need to have documentation for the abuse, I would suggest keeping the documentation in the current repo in Wiki section.

Hosting documentation

We need to have documentation for the hosting, I would suggest keeping the documentation in the current repo in Wiki section.

Make it possible to not rely on a private, global `leasewebClient`

Problem

Currently to use the SDK one needs to call InitLeasewebClient which initializes the private leasewebClient struct as a global variable which is then used by other structs like DedicatedServerApi to execute requests.

This approach makes it hard to work with multiple accounts (and API keys) as from my understanding, I would need to call InitLeasewebClient each time I want to switch the API key used, which makes unnecessary initialization of a new HTTP client each time.

Furthermore given that it is a global variable it prevents any concurrency usage across different accounts' API requests.

Possible solution

Make it possible to initialize LeasewebClient from the outside instead of relying on a global variable. This would require some changes to all APIs clients as now those would need to reference an instance of LeasewebClient. For ease of use for some people globally initialized client can be a default (it is a pattern a lot of libraries follow).

Virtual Servers documentation

We need to have documentation for the virtual servers, I would suggest keeping the documentation in the current repo in Wiki section.

Invoice documentation

We need to have documentation for the invoice, I would suggest keeping the documentation in the current repo in Wiki section.

IP Management documentation

We need to have documentation for the IP management, I would suggest keeping the documentation in the current repo in Wiki section.

Floating IP documentation

We need to have documentation for the floating IP, I would suggest keeping the documentation in the current repo in Wiki section.

Services documentation

We need to have documentation for the services, I would suggest keeping the documentation in the current repo in Wiki section.

Dedicated Server documentation

We need to have documentation for the dedicated Server, I would suggest keeping the documentation in the current repo in Wiki section.

Private Cloud documentation

We need to have documentation for the private cloud, I would suggest keeping the documentation in the current repo in Wiki section.

Dedicated rack documentation

We need to have documentation for the dedicated rack, I would suggest keeping the documentation in the current repo in Wiki section.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.