About REST Service Connection

Configuring a REST Service Connection in FlowOn Logic is essential for successful integration with external RESTful services. Precise configurations enable seamless communication with external REST APIs, ensuring both understanding of their structure and secure access. In the following sections, we'll delve deeper into these critical configuration properties, guiding you through the process of setting up a REST Service Connection for effective integrations.

URL

A fundamental component of any service connection is the URL. It specifies the exact endpoint or location of the external service or API. By providing the URL, you're essentially directing FlowOn Logic to the right "door" of the service you wish to connect to. It is mandatory to define this endpoint to facilitate the communication.

Example For instance, if you're looking to integrate with Uber's API, the endpoint URL might look something like this:

https://api.uber.com

OpenAPI Specification

The OpenAPI Specification, typically provided in the form of a JSON file, serves as an extensive document that comprehensively outlines an API's operations, parameters, and functionalities.

Example Let's take Uber as an illustrative case. Within Uber's OpenAPI Specification, you would discover a wealth of information on how to interact with their API effectively. This includes precise instructions on how to request a ride, complete with the necessary input parameters like pickup and dropoff locations. Additionally, it encompasses the potential outcomes of such requests, such as the estimated cost of the ride, driver details, and the expected time of arrival (ETA). Think of it as a roadmap, a detailed guide that FlowOn Logic on precisely how to engage with the Uber API.

For instance, consider the scenario of wanting to retrieve specific details about a particular ride using Uber's API. In this context, the OpenAPI Specification would provide explicit guidance on the necessary API endpoints, request parameters, and expected response data structures to accomplish this task effectively.

paths:
 /rides/{rideId}:
   get:
     summary: Get details of a specific ride.
     parameters:
       - name: rideId
         in: path
         description: ID of the ride to fetch.
         required: true
         schema:
           type: string
     responses:
       '200':
         description: Successful operation.
         content:
           application/json:
             schema:
               $ref: '#/components/schemas/Ride'

Security Schemes

In the realm of REST API integration, security takes center stage as a critical concern. Security Schemes play a pivotal role in ensuring the protection of sensitive data and the establishment of secure and controlled interactions between various services. These schemes encompass a diverse range of authentication and authorization mechanisms tailored to the specific requirements of REST APIs and services, safeguarding data and ensuring secure connectivity.

These mechanisms validate the identity of users or systems attempting to access the API and determine the level of access they have. Commonly used security schemes include:

1- Basic

Imagine this as the simplest lock and key. It's like putting a password on your phone or computer. You have to enter the right code to get in, and if you don't know the code, you can't get access. Basic Security keeps things straightforward and safe.

Property	Required	Description
Username	Yes	A unique identifier that grants access to the system. It's like your username on a website or application.
Password	Yes	A secret combination of characters that must be entered correctly to gain access. It acts as a protective barrier against unauthorized users.

2- API Key

Think of an API Key as a digital ticket. You need this ticket to enter a special event (like accessing certain information or services). If you have the ticket (the API Key), you can get in. If you don't have it, you're not allowed inside. It's a way to make sure only the right people get access to certain things.

Parameter	Required	Description
Key	Yes	The API Key used for authentication.
Value	Yes	The specific value of the API Key.
Location	Yes	Indicates where the API Key should be placed within an API request for proper authentication.(Body / Query Params / Header)

3- OAuth 2.0

OAuth 2.0 is like asking for permission. Imagine you want to borrow someone's bike. You don't just take it; you ask them, and they decide whether to give you access or not. OAuth 2.0 works the same way; it lets you use something, but only if you've asked and been granted permission. It's all about making sure things are secure and only accessible to those who should have access.

Flow Type	Parameter	Required	Description
Authorization Code	Access Token Url	Yes	The URL where the access token can be requested.
	Client Id	Yes	A unique identifier for the client application.
	Client Secret	No	A secret known only to the client application.
	Credentials Location	No	Send client credentials in the request body / Send as Basic Auth header
	Scope	No	The scope of access requested by the client.
	State	No	A random value to protect against CSRF attacks.
	Callback URL	No	The URL to which the user is redirected after authorization.
	Auth Url	No	The URL where the user is redirected to authorize the client.
Client Credentials	Access Token Url	Yes	The URL where the access token can be requested.
	Client Id	Yes	A unique identifier for the client application.
	Client Secret	No	A secret known only to the client application.
	Credentials Location	No	Send client credentials in the request body / Send as Basic Auth header
	Scope	No	The scope of access requested by the client.
Implicit	Client Id	Yes	A unique identifier for the client application.
	Client Secret	No	A secret known only to the client application (not commonly used in Implicit Flow).
	Credentials Location	No	Send client credentials in the request body / Send as Basic Auth header
	Scope	No	The scope of access requested by the client.
Password Credentials	Client Id	Yes	A unique identifier for the client application.
	Client Secret	No	A secret known only to the client application.
	Credentials Location	No	Send client credentials in the request body / Send as Basic Auth header
	Scope	No	The scope of access requested by the client.
	Username	Yes	The username of the resource owner (user).
	Password	No	The password of the resource owner (user).