Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Applications are developed in-house or by 3rd parties to implement the Organization’s use cases and business logic. These can be either existing dashboards where assets from FinP2P are presented alongside assets from other sources (such as public shares), or new applications for management of assets or a user’s portfolio of investments.

Having a standard specification of this layer allows for an open ecosystem of applications and services for financial institutions to choose from and work with.

Application API Main Functionality

An application integrates with the API to:

  • Manage Users 

    • Manage a User profile with an associated FinID

    • Manage User Certificates and Documents

  • Manage Assets 

    • Manage an Asset Profile, KYA Certificates and Documents

    • Manage an Issuer Profile

  • Manage Asset Tokens 

    • Asset Token Issuance, transfer, redeem

    • Atomic Swap an Asset against a Cash asset

  • Manage Service Providers

    • Manage Service provider profiles (such as Certificates service provider, or regulation enforcement service providers)

  • Query for transaction data, asset data, user balance etc.

The Application API abstract and hides from the application developer all the implementation complexities described above. And, in conjunction with the FinP2P network protocol, it abstracts the topology of the network by routing local and remote requests transparently.

Data model

For more on the data model utilized by the Application API please check the FinP2P Data Model

API Protocol Specifications

The Application API is specified in the OpenAPI 3.0 format. Requests and responses can be crafted with auto-generated code using Swagger Codegen or OpenAPI Generator, are human-readable (easy to debug and understand), and can be used in servers and browsers.

The transactional API conforms to REST. It has predictable, resource-oriented URLs, and it uses HTTP response codes to indicate API errors. JSON is returned by all API responses, including errors

The query API conform to GraphQL, as such it offers significantly more flexibility for the application development. The ability to define precisely the data you want—and only the data you want—is a powerful advantage over the REST. GraphQL lets you replace multiple REST requests with a single call to fetch the data you specify.

The GraphQL data query language is a specification. It determines the validity of the schema on the API server. The schema determines the validity of client calls. The schema defines an API's type system and all object relationships.
An application layer - GraphQL is not a storage model or a database query language. The graph refers to graph structures defined in the schema, where nodes define objects and edges define relationships between objects. The API traverses and returns application data based on the schema definitions, independent of how the data is stored.

API Detailed Specifications

FinP2P Specifications repository on Github contains the detailed specifications for finp2p protocols, and the detailed specification for the Application APIs. The main goal of this repository is to provide accurate reference documentation for the aspects of finp2p that are independent of language or implementation.

  • No labels