cloudnode-pro/ts-client

A client library for the Cloudnode API, written in TypeScript.

ts-client's Issues

Move depenendencies as dev-deps?

Our dependencies currently are @types/node, listr-inquirer, listr2, mustache, node-fetch.

I think we can move all of these except node-fetch to dev dependencies.

Wrong error thrown on login endpoint

When invalid credentials are provided, 422 INVALID_DATA is thrown instead of 401 UNAUTHORIZED.

401 requires WWW-Authenticate but the login endpoint does not use Authorization i.e. HTTP authentication schemes, hence 401 is inappropriate here. This was changed internally in the API as part of our process of deprecating basic authentication.

This inaccuracy somehow made it onto the main branch here 😬

Change is needed here:

ts-client/schema.json

Lines 594 to 597 in 99af42f

	{
	"status": 401,
	"type": "Error & {code: \"UNAUTHORIZED\"}"
	},

CommonJS compatibility

Allow importing using cjs require()

Add `throws` definitions for new page methods

Define that Cloudnode.Error is thrown by inheritance from .#sendRequest in the new page methods such as .getPage, .getNextPage etc

Methods to fetch more pages

When paginated data is returned, add methods to fetch next page as well as all possible pages

Build a browser-friendly SDK

Add a template to generate a separate browser-friendly (non-Node JS) SDK. Or perhaps use some plugin to convert the existing .js to a browser-compatible version.

Smart rate limit handling

Add an option to automatically respect the rate limits by retrying and intentionally delaying requests.

My idea behind this is to avoid sending requests which the client already knows will be rate limited (based on data from recent requests) as to allow the request to still complete after the limit resets instead of failing immediately.

This is just an idea. Further discussion is encouraged

Note: sending an OPTIONS request allows you to check the current rate limit status without decreasing the remaining limit.

Generate readme with docs

Use the JSDoc or the .d.ts or the schema perhaps to generate documentation for the library in the project readme

Include request details in response

Include data such as response headers and status in method return values.

Ideally this should be under a getter with a name that will never collide with the name of a property from a response object.