The following is a guide for implementing a new Ark Client SDK. It covers the required functionalities as well as guidelines for how clients should typically look and behave.
These guidelines are to be strictly followed if you are implementing or modifying an API client for the Ark Ecosystem.
Following these guidelines is required to provide a streamlined experience across different languages to make it easier for new developers to get started with developing a new package or modify an existing one without lowering the quality of the already existing implementation.
Carefully read those guidelines and abide by them while developing an API client.
This can be omitted in languages which have no concept of objects and thus making it impossible to store connection objects.
Gothat is strict and requires you to provide a struct you should fully reflect the original API response in your struct.
createTransactionmethod that sends a signed transaction to the API and the method itself would create the signed transaction instead of expecting it as an argument.
ark-nodeit is required to send your transactions to the P2P API because there is no Public API endpoint for doing this. With the introduction of
ark-coreand the revamped Public API, there is no longer the need to use the P2P API.
If you need to use the
Ark name, keep these 2 use-cases in mind. The first one is
ARK which is used in financial contexts like
10 ARK. The second is
Ark which used for everything else that is not talking about
ARK, the financial unit.
If you need to namespace something with a numerical value in it, write out the numerical value. An example would be
App\Versions\One instead of
If you work with a language that provides standard interfaces for HTTP messaging, implement them to provide a standardized and compliant interface which allows other developers to inject dependencies. An example of this would be PSR-7 for PHP which allows developers to create HTTP clients that follow a standardized interface which allows switching implementations while knowing it will work.
Depending on if you are working with an
Object Oriented Programming Language or
Functional Programming Language the tools at your disposal for how to implement the required functionality will differ.
If you for example work with an OOP language you will be able to isolate functionality into
Objects whereas you won't be able to do that with a Functional language but instead need to think of everything as
There are already a few implementations of cryptography packages available, so take a look at them and decide which approach is the right one for your language.