Prerequisite for backend api Integration
Table of Contents
Spintly provides API (Application Programming Interface) to Add users, modify permissions etc. This document provides help to developers who are in role to develop the integration
Format
The Spintly API supports JSON only, so please set Accept and Content-Type to application/json. All requests and responses will use JSON as the format for any data encompassed in the body of requests and responses.
Authentication
In order to access Spintly APIs, authentication is required. We use oAuth2 based authentication for our APIs. If you haven't worked with oAuth2 before, please familiarize yourself by reading the following details
Microservices
Spintly platform is built with lot of different microservices,
Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.
Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.
For more please read https://aws.amazon.com/microservices/
REST API
A REST API (also called a RESTful API or RESTful web API) is an application programming interface (API) that conforms to the design principles of the representational state transfer (REST) architectural style. REST APIs provide a flexible, lightweight way to integrate applications and to connect components in microservices architectures.
JWT TOKEN
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
JWTs (JSON Web Tokens) can be signed using either symmetric or asymmetric encryption algorithms. The choice between symmetric and asymmetric methods depends on the security and usage requirements of your application. Here’s a breakdown of each approach:
Symmetric JWT (HMAC)
-
Algorithm: HMAC (Hash-based Message Authentication Code), typically
HS256
,HS384
, orHS512
. - Key: Uses a single shared secret key for both signing and verification.
-
How It Works:
- The issuer signs the token with the shared secret.
- The receiver verifies the token’s authenticity using the same secret key.
-
Pros:
- Faster and simpler to implement.
- Only requires one secret, making it more straightforward for internal services or single-server setups.
-
Cons:
- Both the issuer and the verifier must know the secret key, which can increase the risk of exposure, especially in multi-service environments.
- It can be hard to securely share the key across multiple systems without risking leaks.
Asymmetric JWT (RSA/ECDSA)
-
Algorithm: RSA or Elliptic Curve Digital Signature Algorithm (ECDSA), such as
RS256
,RS384
,RS512
,ES256
, etc. - Key: Uses a public/private key pair.
-
How It Works:
- The issuer signs the token with a private key.
- The receiver verifies the token using a public key.
-
Pros:
- More secure for distributed systems: the private key can remain on the issuer’s server, while the public key can be distributed freely.
- Public keys can be rotated or revoked without needing to update clients holding the public key.
- Enables easier multi-service integrations, as each service only needs the public key to verify tokens.
-
Cons:
- Slightly more complex to implement, and RSA encryption is generally slower than HMAC.
- Requires managing public and private key pairs and possibly implementing key rotation strategies.
EPOCH TIME
The below Spintly apis has starttime and endtime needed to be given in epoch time
What is epoch time?
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Literally speaking the epoch is Unix time 0 (midnight 1/1/1970), but 'epoch' is often used as a synonym for Unix time. Some systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038). The converter on this page converts timestamps in seconds (10-digit), milliseconds (13-digit) and microseconds (16-digit) to readable dates.
For more information about epoch time you can refer the below site https://www.epochconverter.com/
Epoch Time is available in all programing languages
POSTMAN
Spintly provides postman apis for the client to test via posman, so make sure you have postman installed, before integrating the apis in your application
What is postman
Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
JWT.IO()
As in the Spintly integration, lot of tokens will be involved, so this tool will be handy to decode the token etc
https://jwt.io/introduction
OAuth 2.0 Client Credentials Grant
The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user.