Showing posts with label API(Application Programming Interface). Show all posts
Showing posts with label API(Application Programming Interface). Show all posts

Thursday, July 3, 2025

API Fundamentals

API Fundamentals: Your Restaurant Analogy

Imagine you're at a restaurant. You, as the customer, want to order some food. You don't go into the kitchen, grab ingredients, and cook your meal yourself. Instead, you interact with a waiter using a menu.

  • You (the Customer) = The Client Application: This is your software (e.g., a mobile app, a website, a script) that needs a service or data from another system.
  • The Menu = The API Documentation: This defines what you can order (the available functions or data), how to order it (the format of your request), and what you can expect to receive.

  • The Waiter = The API Gateway / Server: This is the intermediary. It takes your order (request), translates it into something the kitchen understands, sends it to the kitchen, waits for the food, and then brings it back to you (the response). It also handles rules like "Are you allowed to order this?" (authentication/authorization).

  • The Kitchen = The Backend System / Database: This is where the actual work happens. It processes the order, retrieves or manipulates data, and prepares the result.

Conceptual Diagram:

Let's visualize this flow:



How Does It Work in Detail?

Let's expand on the components using this analogy and then a real-world software example.

1. The Client (You / Your App)

  • Your application needs specific information or wants to trigger an action on another system.
  • It sends a request to the API.

2. The Request (Your Order)

This is what you communicate to the waiter. In software terms, an API request typically consists of:

  • Endpoint (What you want): This is like a specific item on the menu. For a weather API, an endpoint might be /current_weather or /forecast. It's a specific URL.
    • Analogy: "I want the 'Spicy Chicken Burger'."

  • HTTP Method (How you want it): This specifies the type of action.
    • GET: To retrieve data (e.g., "Get me the menu").
      • Analogy: "I'd like to GET the daily specials."
    • POST: To create new data (e.g., "Place a new order").
      • Analogy: "I want to POST a new order for a pizza."
    • PUT/PATCH: To update existing data (e.g., "Change my order").
    • DELETE: To remove data (e.g., "Cancel my order").

  • Headers (Extra instructions): Metadata about the request, like your authentication token (are you a VIP customer?), the type of content you're sending, or the type of content you expect back.
    • Analogy: "Here's my loyalty card." or "I prefer my food well-done."
  • Body (Details of your order): For requests that create or update data (POST, PUT, PATCH), the body contains the actual data you're sending. This is often in JSON (JavaScript Object Notation) format, which is like a structured, easy-to-read list of ingredients and instructions.
    • Analogy: "For my pizza, I'd like pepperoni, mushrooms, and extra cheese." (This is the "data" in your order).

3. The API Gateway / Server (The Waiter)

  • Receives your request.
  • Validates it: Checks if the request is correctly formatted and if you have the necessary permissions (authentication and authorization).
  • Routes it: Directs the request to the correct part of the backend system (the kitchen).

4. The Backend System (The Kitchen)

  • Processes the request. This could involve querying a database, running a complex algorithm, or interacting with other internal services.
  • Prepares the response.

5. The Response (Your Food)

  • The backend system sends the result back to the API server.
  • The API server then sends a response back to the client. This response typically includes:
    • Status Code (How did it go?): A numerical code indicating the outcome of the request.
      • 200 OK: Everything went well (you got your food!).
      • 404 Not Found: The resource you asked for doesn't exist (that dish isn't on the menu).
      • 401 Unauthorized: You're not allowed to make this request (you don't have a reservation).
      • 500 Internal Server Error: Something went wrong on the server's side (the kitchen had a problem).
    • Headers: Metadata about the response (e.g., how long the food took to prepare, the type of content being sent back).
    • Body: The actual data requested, often in JSON format.
      • Analogy: Your plate of food, presented nicely.

Real-World Software Example: A Weather App

Let's imagine you have a weather app on your phone.

  1. You (Client Application): Open your weather app.
  2. Request (to Weather API): Your app sends a request to a weather service's API.
    • Endpoint: https://api.weather-service.com/v1/current_weather
    • HTTP Method: GET (because it wants to retrieve data)
    • Headers: Might include an Authorization header with an API key to identify your app.
    • Body (or Query Parameters): ?location=Paris (asking for weather in Paris)
  3. API Gateway / Server (Weather Service): The weather service's server receives this request. It validates the API key and understands you're asking for current weather in Paris.
  4. Backend System (Weather Service Database/Logic): The server's backend queries its internal weather data, probably from various weather stations and forecast models, to get the current conditions for Paris.
  5. Response (from Weather API): The weather service sends back a response.
    • Status Code: 200 OK (success!)
    • Body (JSON):
    • {
    •   "location": "Paris, France",
    •   "temperature": {
    •     "celsius": 22,
    •     "fahrenheit": 71.6
    •   },
    •   "conditions": "Partly Cloudy",
    •   "humidity": 65,
    •   "wind_speed_kmh": 15
    • }
  6. Your App (Client Application): Receives this JSON data and displays it beautifully on your screen, showing you the temperature, conditions, etc., for Paris.

Why are APIs So Important?

APIs are the backbone of the modern internet. They allow:

  • Interoperability: Different software systems, often built by different companies, to seamlessly communicate.
  • Modularity: Developers can build complex applications by combining smaller, specialized services (e.g., payment, mapping, social media integrations) without reinventing the wheel.
  • Innovation: They empower third-party developers to create new applications and services on top of existing platforms, leading to a richer digital ecosystem.

I hope this explanation, using the restaurant analogy and a clear software example, helps you grasp the fundamentals of APIs!

 


Thursday, March 21, 2024

APIs on SAP Business Accelerator Hub

 

APIs on SAP 


Ø  An application programming interface (API) is an interface that lets software systems communicate with each other and exchange data.

Ø  By offering an API for your system, we can define which data should be exposed and thereby maintain control. As the consumer of an API, we don’t have to know how the other system works. Instead, we can focus on how it's integrated into your system.

Ø  we can use the APIs available for SAP S/4HANA Cloud for these scenarios:

  • Connect business processes across your system landscape
  • Integrate with external systems
  • Develop your own dependent extensions or custom applications

Inbound and Outbound Services

Ø  APIs can either be inbound or outbound services.

With respect to SAP S/4HANA Cloud as the source system,

Ø  Inbound means that SAP S/4HANA Cloud provides a service that another system can consume.

Ø  Outbound means that SAP S/4HANA Cloud consumes a service that is provided by another system.

 Synchronous and Asynchronous Services

APIs can either be synchronous or asynchronous services.

Ø  Synchronous means that when a system sends a request it waits for the receiving system to send a response. This approach is useful if an immediate and real-time response is required. However, both systems need to be online the entire time and if there’s an error, the request has to be sent again.

Ø  Asynchronous means that when a system sends a request it waits for the receiving system to acknowledge receipt of the message. However, it doesn’t wait for the receiving system to send a response. This way you can loosely couple systems and there’s less dependency on the availability of the other system. Additionally, the sender system isn’t blocked after sending a request and can send further requests. With this approach, you get no immediate response, and a response message needs to be implemented and routed separately.

Communication Scenarios

To establish secure communication between systems, you first need to create a communication arrangement. Communication arrangements are based on a communication scenario. Predefined communication scenarios are available for different use cases, for example, the integration of employee data. In a communication scenario, you can define a set of inbound and outbound services for a business process. Each API on SAP Business Accelerator Hub is associated with at least one communication scenario. With the communication scenario, you get an idea of the best practices for using the API. For more information, see Communication Management.

Service Categories

APIs created by SAP are categorized according to the main purpose of the messages being communicated. These service categories exist:

Application-to-Application (A2A)

A2A services facilitate the exchange of business information between different systems to connect business processes within company borders.

 Application-to-Cross Application (A2X)

A2X services facilitate the exchange of business information between a system and an unspecified client. They’re often used to build user interfaces (UIs) based on the back end, without an intervening communication layer. For this reason, A2X messages contain all the necessary information for understanding the message, such as the code names or texts to be displayed on the UI.

Business-to-Business (B2B)

B2B services facilitate the exchange of business documents across companies.

Source:https://help.sap.com/docs/SAP_S4HANA_CLOUD/0f69f8fb28ac4bf48d2b57b9637e81fa/1e60f14bdc224c2c975c8fa8bcfd7f3f.html

Friday, December 22, 2023

What is payload in SAP

 What is payload in SAP with example of Material Master

            A payload in SAP can be thought of as the important information or data that is sent and received when different systems communicate with each other. Imagine we are sending a package from one place to another and the payload is the actual content inside that package.

Example:

Ø  In SAP, when we are working with APIs (ways for different software systems to talk to each other), the payload is like the contents of a message.

Ø  If we are updating information about a product (let's say a laptop) in SAP, the payload would include details like the laptop's name, brand, specifications, and any other relevant information.

Ø  So,in short, think of the payload as the meaningful data that is being exchanged between different parts of the SAP system or between SAP and other systems. It's the valuable stuff inside the digital "package" being sent or received.

                 In the context of SAP and APIs (Application Programming Interfaces), a payload refers to the data that is transmitted between systems in a request or response. It contains the actual information that is being sent or received, and it typically adheres to a specific data format, such as XML or JSON.

                 For material master data in SAP, the payload would include the details about a material, such as its description, classification, attributes, and other relevant information. The payload format can vary depending on the specific API or integration scenario.

Here's a simplified example of a JSON payload for creating or updating a material master in SAP:

JSON Copy code

{ "MaterialID": "M12345",

"Description": "Product ABC",

"Category": "Electronics",

"Price": 100.00,

 "UnitOfMeasure": "EA",

"Vendor": "VENDOR123",

"StockDetails": { "Plant": "PLANT001",

"StorageLocation": "STORAGE001",

 "Quantity": 100 } }

In this example:

MaterialID: Unique identifier for the material.

Description: Descriptive name of the product.

Category: Categorization of the material (e.g., Electronics).

Price: Price of the material.

UnitOfMeasure: Unit of measure for the material (e.g., Each).

Vendor: Vendor code associated with the material.

StockDetails: Additional details related to stock, including the plant, storage location, and quantity.

It's important to note that the actual structure and fields in the payload would depend on the specific requirements of the SAP API we are working with. SAP typically provides API documentation that outlines the expected payload format for different operations, such as creating, updating, or retrieving material master data. Always refer to the relevant SAP API documentation for accurate and up-to-date information.

Sunday, December 17, 2023

Type of API requests in SAP

 

                      In SAP, various API requests can be made to interact with different modules and functionalities within the system. The most common types of API requests in SAP include:

GET Requests:

Purpose: Retrieve data from the SAP system.

Example: Fetch information about customers, products, or other entities stored in the SAP system.

POST Requests:

Purpose: Create new data or entities in the SAP system.

Example: Add a new sales order, create a new employee record, or submit a purchase requisition.

PUT/PATCH Requests:

Purpose: Update existing data or entities in the SAP system.

Example: Modify customer details, update inventory levels, or change the status of a work order.

DELETE Requests:

Purpose: Remove data or entities from the SAP system.

Example: Delete a customer record, remove an employee from the system, or cancel a sales order.

Batch Requests:

Purpose: Combine multiple API operations into a single request to improve efficiency.

Example: Execute multiple update operations in a single batch request instead of making individual requests.

Query Parameters:

Purpose: Refine the data retrieved by specifying parameters in the request URL.

Example: Retrieve all sales orders created after a certain date or get a list of employees in a specific department.

OData Requests:

Purpose: Use the OData protocol for building and consuming RESTful APIs in SAP.

Example: Query and manipulate data in SAP Business Suite using OData services.

SOAP Requests:

Purpose: Interact with SAP systems using the SOAP (Simple Object Access Protocol) protocol.

Example: Access SAP web services for functionalities like authentication, data retrieval, or data modification.

These are general categories and the specific API requests and functionalities may vary based on the SAP module or product we are working with. SAP provides a range of APIs for different purposes, such as SAP S/4HANA APIs, SAP Fiori APIs, and SAP NetWeaver APIs, among others.

What is an API in simple explanation

 

An API (Application Programming Interface) is a set of rules and protocols that allows different software applications to communicate with each other. It defines how different software components should interact, making it easier for developers to integrate and use the functionality of one software system in another.

 

Example1: API in Layman words:

Ø  Think of it as a waiter taking your order at a restaurant.

Ø  You (the client) don't need to go to the kitchen and cook the food yourself (interact directly with the server).

Ø  Instead, you communicate your order to the waiter, who then conveys it to the kitchen and brings the food back to you.

Ø  Similarly,in SAP, different software systems or applications (like a website, mobile app, or third-party software) may want to access or use data and functions from SAP systems.

Ø  The API acts as the intermediary or waiter, allowing these external systems to make requests (place orders) for specific data or actions from the SAP system. The SAP system processes the request and provides the necessary information, just like the kitchen preparing your food.

 Example2:Simple API flow how it works in a Restaurant:



                       In this way, APIs facilitate smooth communication between different software, enabling them to work together seamlessly, even if they are from different vendors or serve different purposes.

There are several types of APIs, and they can be categorized based on their purpose and how they expose functionality. Here are some common types of APIs with examples:

Open APIs (Public APIs):

Definition: Open APIs, also known as public APIs, are accessible to developers and third-party applications with minimal restrictions. They are designed for external users and developers and are publicly available.

Example: Twitter API, Google Maps API, OpenWeatherMap API.

Internal APIs (Private APIs):

                   Internal APIs, or private APIs, are used within organizations and are not exposed to external developers. They are designed to improve code reusability, maintainability, and collaboration among internal teams.

Example: An e-commerce company using internal APIs to connect their inventory management system with their order processing system.

RESTful APIs:

                      REST (Representational State Transfer) is an architectural style for designing networked applications. RESTful APIs adhere to the principles of REST and use standard HTTP methods (GET, POST, PUT, DELETE) for communication.

Example: GitHub API, Dropbox API, Facebook Graph API.

SOAP APIs:

                SOAP (Simple Object Access Protocol) is a protocol for exchanging structured information in web services. SOAP APIs use XML for message formatting and are known for their strict standards.

Example: Web services in enterprise systems like SAP, Salesforce, or Microsoft Dynamics.

GraphQL APIs:

                   GraphQL is a query language for APIs that allows clients to request only the data they need. It provides a more flexible and efficient alternative to traditional REST APIs.

Example: GitHub GraphQL API, Shopify GraphQL API.

Webhooks:

                    Webhooks are a way for one system to provide real-time information to another system by sending HTTP callbacks or notifications when an event occurs.

Example: GitHub Webhooks for receiving notifications about repository events, Stripe Webhooks for payment events.

Library-based APIs:

                Library-based APIs provide a set of functions and procedures that can be used by applications. They are often packaged as libraries that developers can include in their code.

Example: Java Standard API, .NET Framework Class Library.

 

Looking for remote work opportunities in 2026

Here are 27 platforms that offer remote job opportunities: -Remotive ( https://lnkd.in/gUQ7vrVq ) -Toptal ( toptal.com ) -Skip The Drive ( h...