astarte-platform / astarte-go Goto Github PK

The client package provides a too vast set of functionalities and, despite so, makes it difficult to further customize the current req/res mechanism (e.g. there is no way of retrieving raw Astarte data, or see #20). Moreover, the current API does not use a state-of-the-art approach to building and executing HTTP calls.
As stated in #30, the package should be rationalized and a more idiomatic style is to be enforced.

All the HTTP requests should also return the status code. This change will break the API

After reworking the structure of the astarte-go library (see #30), the APIs will be not compatible with the 0.90.x releases. Thus, a new set of guidelines and good practices will be available.

In this context, provide an effective walkthrough for migrating to and using the new version of the library.

As stated in #30, functionalities currently in the misc package will be split in two packages. See title.

Right now only RSA keys are supported, and we're trying to move towards EC keys since they're future-proof, they're shorter and they generate shorter JWTs.

Since astarte-platform/astarte#583, Trigger Delivery Policies are a thing. Support installing and deleting them, and referencing a Policy in a Trigger.

The current API is quirky and difficult to integrate as a dependency, especially for AppEngine-related functions.
Provide a new, polished and idiomatic API.

The following packages will be exported:

• interfaces: interface parsing and validation,
• device-utils: Astarte device ID generation and handling (e.g. conversion to/from UUID),
• auth: all things related to Astarte auth (via JWT),
• client: HTTP client for Astarte services aimed at interacting with the Astarte APIs and parsing retrieved data.
• data: parsing functions for data retrieved using the client package.

This is a major change, and possibly breaking. As such, parts of the current codebase will be rewritten: as the Go modules reference suggest, a v0 version does not signal stability or backward compatibility guarantees.
The old API will be supported for now (see the release-0.90 branch), and deprecated in the future.
A migration path to the new API should be provided, along with documantation on new guidelines and good practices.

This is a meta issue to keep track of all changes required.

Currently, data parsing is intertwined with HTTP-related functions in the client package. As stated in #30, we should move it away and rationalize code.

This partially relates to #33.

As stated in #30, the interfaces package APIs will be reworked and rationalized.