Your business relies on a suite of software, from your CRM to your accounting tools. The problem is, they often don't speak the same language. This leads to manual data entry, wasted time, and costly errors. REST APIs solve this by acting as universal translators, creating seamless bridges between your most critical applications. They are the engine behind true workflow automation. In this rest api tutorial, we'll show you how these powerful interfaces work and how you can use them to connect your systems, automate processes, and drive efficiency across your entire organization.
Key Takeaways
- Use REST APIs as a common language for your software: They rely on standard web protocols to allow different applications to communicate seamlessly, forming the foundation for modern, integrated systems.
- Structure API calls with verbs and nouns: A REST API works by using HTTP methods (the verbs, like GET or POST) to perform actions on specific resources (the nouns), which are identified by their unique URL endpoints.
- Connect your systems to automate workflows: By acting as the bridge between your business applications, REST APIs make it possible to build automated processes that reduce manual work and improve efficiency, especially within a low-code environment.
What Is a REST API?
Think of an API (Application Programming Interface) as a menu at a restaurant. It shows you what you can order and gives you a clear way to make your request. A REST API is a specific, and very popular, type of menu that follows a set of design principles known as "REST architecture." While REST stands for Representational State Transfer, you don't need to get bogged down in the technical term. The key takeaway is that it uses standard internet connections (HTTP) to function, which makes it incredibly versatile and widely adopted.
One of the core principles of REST is that it's "stateless." This simply means the server doesn't store any information about the client between requests. Every time your application communicates with the API, it must provide all the necessary context, as if it's their first time speaking. This might sound repetitive, but it makes the entire system more reliable and much easier to scale. Because REST APIs are so straightforward and efficient, they have become the standard for building web services. They allow you to perform basic tasks like creating, reading, updating, or deleting information using simple commands. This is why they are fundamental to connecting different software systems and form the backbone of modern iPaaS solutions that help businesses automate processes across various applications.
REST, SOAP, and GraphQL: What's the Difference?
As you explore APIs, you'll also encounter terms like SOAP and GraphQL. It helps to think of these as different languages that applications can use to communicate. SOAP (Simple Object Access Protocol) is an older, more rigid protocol with strict rules. It uses a heavier data format called XML, which can sometimes make it slower than REST. In contrast, REST is generally easier for developers to learn and use because it leverages standard web protocols and often uses lightweight data formats like JSON.
GraphQL is a newer alternative that was developed by Facebook. Its main advantage is precision. With GraphQL, the client application can ask for exactly the data it needs in a single request. This solves a common REST issue where you either get too much data (over-fetching) or have to make multiple API calls to get everything you need (under-fetching). While GraphQL is powerful, REST remains the most common choice because it offers a fantastic balance of performance, flexibility, and simplicity.
What Makes an API "RESTful"?
"REST" isn't just a name; it's a set of architectural constraints. Think of them as the ground rules for creating a clean, predictable, and scalable API. When an API follows these rules, we call it "RESTful." It’s a bit like following a recipe. You can add your own flair, but you need to stick to the core ingredients and steps to get the result you want. These principles ensure that the API is decoupled and that its components can evolve independently. This is crucial for building robust applications, especially in complex enterprise environments where different systems need to communicate seamlessly. Understanding these constraints is the first step to designing APIs that are not just functional but also efficient and easy for other developers to use. Let's break down what these core principles are.
Statelessness
Imagine having a conversation where you have to reintroduce yourself with every single sentence. That’s the core idea behind statelessness. Each request sent from the client to the server must contain all the information the server needs to understand and process it. The server doesn't remember anything about the client from previous requests. This might sound inefficient, but it makes the system incredibly reliable and scalable. Since every request is self-contained, it can be handled by any server in a cluster, which simplifies server design and makes it easier to manage high traffic loads.
Client-Server Architecture
The client-server model creates a clear separation of concerns. The client (your application's user interface) is responsible for the presentation, while the server is responsible for storing and managing the data. They are two separate entities that communicate over a network. This separation is powerful because it allows the client and server to evolve independently. Your front-end team can redesign the user experience without touching the back-end logic, and your back-end team can improve the database performance without affecting the client. This flexibility is key to building modern, scalable applications and is a core part of how iPaaS solutions connect disparate systems.
Uniform Interface
A uniform interface is like a universal language that both the client and server agree to use. This principle simplifies the entire system because developers don't have to learn a completely new set of rules for every API. It creates a consistent, predictable way to interact with resources on the server. This is achieved through a few key constraints, like using standard HTTP methods (GET, POST, PUT, DELETE) for operations and using URLs to identify specific resources. By standardizing communication, you make your API more accessible and easier for other developers to understand and integrate into their own applications.
Cacheability and Layered Systems
These two principles work together to improve performance and scalability. Cacheability means the server can mark a response as cacheable. The client can then store that response for a period and reuse it for subsequent identical requests, which reduces the load on the server and makes the application feel faster. A layered system means that the communication between a client and server can pass through intermediary layers, like load balancers or security proxies, without the client knowing. The client only interacts with the endpoint it's given, while the underlying architecture can be scaled or secured behind the scenes. This adds a ton of flexibility to your system's design.
Speaking REST: Your Guide to HTTP Methods
If you think of a REST API as a language for talking to a web service, then HTTP methods are the verbs. They tell the server what action you want to perform on a specific resource. While there are several methods available, you'll find that a handful of them do most of the heavy lifting in any API you build or use. Understanding these core methods is the key to communicating effectively with any RESTful service, forming the foundation for powerful integrations and workflow automation. Let's walk through the most common ones you'll encounter.
GET: How to Retrieve Data
The GET method is the most common and straightforward of the bunch. Its one and only job is to retrieve data from a server. When you use a GET request, you're simply asking the server for a specific piece of information without making any changes. For example, a request like GET /api/customers/58 is asking for the data associated with the customer who has an ID of 58.
Because GET requests don't alter the state of the server, they are considered "safe" methods. You can send the same GET request over and over again and expect the same result each time, which also makes them idempotent. If the request is successful, the server will typically respond with the data you asked for and a 200 OK status code.
POST: How to Create Resources
When you need to create a new resource on the server, POST is the method you'll use. Unlike GET, a POST request includes a "body" containing the data for the new resource you want to create. Think of it like filling out a form on a website and hitting "submit." For instance, you might send a POST /api/customers request with a JSON object in the body that contains a new customer's name, email, and address.
If the server successfully creates the resource, it will typically respond with a 201 Created status code. Often, the response will also include the data for the newly created resource, along with a Location header that points to the URL of the new resource. This is fundamental for many business processes, like adding a new record in a low-code platform.
PUT and PATCH: How to Update Resources
When you need to modify an existing resource, you have two options: PUT and PATCH. Though they both update data, they work in critically different ways. A PUT request is used to replace an entire resource with a new representation. If you send a PUT /api/customers/58 request, you must include all the data for customer 58 in the request body. Any fields you leave out will be removed or set to null.
A PATCH request, on the other hand, is for making partial updates. It's much more efficient when you only need to change one or two fields. For example, you could send a PATCH /api/customers/58 request with just the customer's new phone number. The server would update only that specific field, leaving the rest of the customer's data untouched.
DELETE: How to Remove Resources
As you might guess from the name, the DELETE method is used to remove a specific resource from the server. It's a straightforward but powerful action. For example, sending a DELETE /api/customers/58 request tells the server to permanently remove the customer with the ID of 58. This action is irreversible, so it should always be implemented with care, often with user confirmation prompts in the front-end application.
If the deletion is successful, the server will usually respond with a 200 OK or a 204 No Content status code to confirm that the resource has been removed. In the context of business process management, this could be used to archive a completed project or remove a canceled order from the system.
How Does a REST API Work?
Think of a REST API as a translator and messenger between two different software applications. It allows a client, like a mobile app, to request information or actions from a server, where the data and logic live. This conversation happens over the internet using the same standard rules that power the web, known as HTTP. Because it uses a familiar protocol, REST is a predictable and straightforward way to get different systems talking to each other.
The entire interaction follows a simple pattern: the client sends a request, and the server sends back a response. It’s a lot like ordering at a restaurant. You (the client) give your order (the request) to the waiter (the API), who takes it to the kitchen (the server). The kitchen prepares your meal, and the waiter brings it back to your table (the response). To make this work, every request needs a clear destination (an endpoint), a specific action (an HTTP method), and a shared language for the data (like JSON). This structure is key to building the connected, automated systems that modern businesses rely on, which is why APIs are a core component of iPaaS solutions that integrate various applications.
Breaking Down the Request-Response Cycle
Every interaction with a REST API is a two-part conversation: a request followed by a response. First, the client sends a request to the server. This request is made up of a few key pieces. It includes an HTTP method that defines the action (like GET to retrieve data), the URL of the resource you want to access, and headers that contain extra information like authentication tokens. If you're sending data to the server, like creating a new user, the request will also have a body containing that information.
Once the server receives the request, it processes it and sends back a response. This response tells the client what happened. It includes a status code, which is a quick signal of success or failure (like 200 OK). It also has its own headers and, if you requested data, a body containing the information you asked for in a format like JSON. This clear, predictable request-response cycle is what makes REST APIs so reliable.
What Are Endpoints and URLs?
In the world of REST, any piece of information that an API can provide is called a "resource." A resource could be a user profile, a product listing, a blog post, or even a collection of items. To access any of these resources, you need to know its address. That address is a specific URL called an endpoint. For example, an API might have an endpoint like /users to represent all users and another like /users/123 to represent a single user with the ID 123.
These endpoints are the specific locations the client sends requests to. By combining a URL with an HTTP method, you can perform different actions on the same resource. For instance, sending a GET request to /users/123 retrieves that user's data, while sending a DELETE request to the same endpoint would remove it. These resource identifiers are the foundation of a well-designed REST API, making it intuitive to understand and use.
Choosing Your Data Format: JSON vs. XML
For two systems to communicate, they need to speak the same language. In the context of APIs, this "language" is the data format used to structure the information being exchanged. While REST is flexible and can support various formats, the most common choice by far is JSON (JavaScript Object Notation). JSON is lightweight, easy for humans to read, and simple for machines to parse, making it a perfect fit for web-based applications. Its structure of key-value pairs maps directly to objects in most programming languages.
Another format you might encounter is XML (eXtensible Markup Language). XML is older and more verbose than JSON, using tags to define its structure, similar to HTML. While it's still used in many enterprise and legacy systems, most modern APIs have standardized on JSON for its efficiency and ease of use. When building integrations, it's helpful to use a platform that can handle multiple data formats to ensure your features connect seamlessly with any system.
HTTP Status Codes You Need to Know
When a server responds to an API request, it always includes an HTTP status code. This three-digit number is a quick and standardized way to tell the client whether the request was a success, a failure, or something in between. You don't need to memorize every single code, but understanding the main categories is essential for building reliable applications.
Codes in the 200s (like 200 OK or 201 Created) mean everything went as planned. Codes in the 400s (like 404 Not Found or 400 Bad Request) indicate a problem with the client's request, meaning you might have used the wrong URL or sent invalid data. Finally, codes in the 500s (like 500 Internal Server Error) signal a problem on the server's end. Understanding these status codes helps you handle different outcomes gracefully in your application.
How to Build Your First REST API
Building your first REST API might sound intimidating, but it’s a straightforward process when you break it down. Think of it as creating a set of rules for how different software applications can talk to each other. Following a clear, step-by-step plan helps you create a functional and reliable API that can serve as the backbone for your applications or integrations. Let's walk through the six essential steps to get your first API up and running.
Step 1: Set Up Your Environment
Before you can write any code, you need a place for it to live and run. This is your development environment. For beginners, a great starting point is to use tools that are widely supported and have plenty of documentation. You can create a basic REST API using Node.js, which lets you run JavaScript code outside of a web browser, and Express, a framework that simplifies building web applications. These tools provide a solid foundation without being overly complex, allowing you to focus on the logic of your API. Setting up your environment correctly from the start saves you headaches down the road and creates a stable base for development and testing.
Step 2: Define Your Resources and Endpoints
Next, you need to decide what data your API will manage. These are your "resources." A resource could be anything: users, products, orders, or any other piece of information. Once you know your resources, you create endpoints, which are the URLs that clients will use to access them. It's a best practice to give easy-to-understand names to your resources, typically using plural nouns. For example, if your API manages customer data, you would use endpoints like /customers to get a list of all customers and /customers/123 to get a specific customer. This clear and predictable structure is a hallmark of a well-designed REST API and makes it intuitive for other developers to use.
Step 3: Implement Your HTTP Methods
With your endpoints defined, it's time to make them do something. This is where HTTP methods come in. These are the verbs that tell your API what action to perform on a resource. As one guide explains, APIs use common internet methods like GET, POST, PUT, PATCH, and DELETE to perform actions. For your /customers endpoint, a GET request would retrieve a list of customers, while a POST request would create a new one. A PUT or PATCH request to /customers/123 would update that specific customer’s information. Implementing these methods is how you bring your API to life and make it interactive, turning static data into a dynamic service.
Step 4: Add Authentication and Data Validation
An open door isn't always a good thing, especially with APIs. You need to control who can access your data and what they can do with it. This is where authentication comes in. It’s crucial to make sure only authorized users can access your API using methods like API keys or OAuth. Just as important is data validation. Before you process any incoming data from a POST or PUT request, you should check that it's in the correct format. This prevents errors and protects your system from malformed or malicious data. These security measures are not optional; they are essential for building a trustworthy and secure API.
Step 5: Plan for Error Handling
Even in the best-designed systems, things can go wrong. A user might request a resource that doesn't exist, or a server might be temporarily unavailable. A great API handles these situations gracefully. Instead of just crashing, your API should send back a clear message explaining what happened. The primary way to do this is with HTTP status codes. As you build, remember that the API sends back a Status Code, a number that tells the client if the request worked, like 200 for success or 404 for not found. Good error handling makes your API more reliable and easier for developers to use, which is critical for adoption.
Step 6: Test Your API with Postman
After you’ve built your API, you need to make sure it works as expected. Manually testing every endpoint and method can be tedious, but specialized tools make it much easier. You can use tools like Postman or Insomnia to manually test your APIs. These applications allow you to send requests to your endpoints, inspect the responses, and check your status codes and data formats. This testing phase is not just about finding bugs; it's also about seeing your API from a user's perspective. Thorough testing helps you catch issues early and ensures that your API is robust and ready for other applications to depend on it.
Best Practices for Designing a Great REST API
Building an API is one thing; building an API that people love to use is another. When you follow design best practices, you create an experience that is predictable, stable, and easy for other developers to work with. This is especially important in business process management, where APIs act as the connective tissue between all your critical applications and services. A well-designed API can streamline integrations, reduce development time, and make your entire system more scalable and maintainable.
Think of it as building a bridge. A poorly designed bridge is confusing, unsafe, and frustrating to cross. A well-designed one is intuitive, reliable, and gets people exactly where they need to go without any fuss. Your API is that bridge for data. By focusing on clarity, security, and a great developer experience from the start, you set your projects and your partners up for success. Let’s walk through some of the core principles that separate a good API from a great one.
Use Clear and Consistent Naming
Clarity is kindness in API design. Your endpoint names should be so intuitive that a developer can guess what they do just by reading them. The best way to achieve this is by using simple, plural nouns for your resources. For example, use /customers to represent a collection of customers and /orders for a collection of orders. This convention is straightforward and widely understood.
Consistency is just as important. If you use /customers to get a list of all customers, the endpoint for a single customer should logically follow that pattern, like /customers/{customerId}. Sticking to a consistent naming scheme across your entire API makes it predictable. Developers won't have to constantly check your documentation to figure out different endpoint structures, which makes the integration process much smoother and faster.
Version Your API
Your business and its software will inevitably evolve, and your API will need to change with them. Versioning is how you manage these changes without breaking existing applications that rely on your API. Imagine a partner has built an integration with your system. If you suddenly change a data field they depend on, their application could fail without warning. This creates instability and damages trust.
By including a version number in your API path, such as /api/v1/customers, you create a stable contract with your users. You can then work on /api/v2/ to introduce new features or make breaking changes. This approach allows you to innovate and improve while giving your partners a clear path and ample time to migrate to the new version. It’s a fundamental practice for professional API management and is a core part of FlowWright's iPaaS solutions.
Secure Your API with Authentication
Security should never be an afterthought; it needs to be a foundational part of your API design. An API is a direct gateway to your application's data and functionality, so you must ensure that only authorized users can access it. Authentication is the process of verifying who is making a request. Common methods include using API keys, bearer tokens, or implementing a protocol like OAuth 2.0.
For any enterprise or government organization, protecting sensitive data is non-negotiable. Implementing strong authentication prevents unauthorized access, protects user privacy, and stops potential abuse of your services. By requiring authentication for protected endpoints, you ensure that your API remains a secure and trusted tool for your business and its partners. This commitment to security is a key aspect of any enterprise-grade features overview.
Validate Incoming Data
A robust API should never blindly trust the data it receives. You must always validate incoming data to make sure it’s in the correct format and meets your requirements before you process it. For example, if your API expects a user's birthdate, it should verify that the input is a valid date and not just a random string of text. If a required field is missing from a request, the API should reject it immediately.
This practice, known as input validation, is your first line of defense against errors and security vulnerabilities. It prevents malformed data from corrupting your database and protects your system from common attacks. By being strict about the data you accept, you ensure data integrity and make your application far more stable and reliable. This is especially critical in systems that handle intelligent document processing, where data accuracy is paramount.
Handle Errors Gracefully
Errors are a fact of life in software, but how your API communicates them makes all the difference. A vague "Error 500" message is frustrating and unhelpful. A great API provides clear, actionable error messages that help developers quickly understand what went wrong and how to fix it. This means using the correct HTTP status codes and providing a descriptive message in the response body.
For instance, if a user tries to create a resource with missing information, your API should respond with a 400 Bad Request status and a message like, "The 'email' field is required." This immediately tells the developer the exact problem. Graceful error handling saves developers hours of frustrating debugging, improves the developer experience, and ultimately makes your API more professional and easier to integrate with.
Write Thorough Documentation
Your API is only as good as its documentation. If developers can't figure out how to use it, they won't. Comprehensive documentation is the user manual for your API, and it should leave no room for guesswork. It needs to detail every available endpoint, the required parameters for each, and the expected format for both requests and responses. It should also include clear examples that developers can copy and paste to get started quickly.
Don't forget to document your authentication methods and list all possible error codes with explanations of what they mean. The best documentation is often interactive, allowing developers to try out API calls directly in their browser. Investing time in great documentation shows that you are committed to empowering developers and partners, making it far more likely that they will successfully integrate with your platform.
Common Mistakes to Avoid
Building your first REST API is a huge accomplishment, but creating one that’s reliable, secure, and easy for others to use requires avoiding a few common traps. A great API not only functions correctly but also communicates clearly and anticipates the needs of its users. By steering clear of these frequent missteps, you can build a more robust and professional API that stands the test of time and provides a much better developer experience for everyone who uses it.
Don't Ignore HTTP Status Codes
Think of HTTP status codes as the API's primary way of communicating. When a developer makes a request, the status code is the first piece of feedback they get about whether it succeeded, failed, or something else happened. Ignoring them is like having a conversation and not listening to the other person's replies. For example, a '200 OK' means everything went smoothly, while a '404 Not Found' clearly states that the requested item doesn't exist. Using these standard HTTP status codes correctly makes your API predictable and much easier to debug.
Don't Skip API Versioning
Your API will inevitably change over time. You’ll add new features, fix bugs, and improve performance. Without a versioning strategy, these updates could suddenly break the applications of everyone who depends on your API. This is a surefire way to frustrate your users. Versioning your API is crucial for managing change gracefully. By creating different versions (like /api/v1/ and /api/v2/), you allow existing users to continue using the stable version they built for, while giving them the option to migrate to the new version on their own schedule. It’s a simple practice that shows respect for your users and their work.
Don't Overlook Security
API security should never be an afterthought; it needs to be a core part of your design from day one. An unsecured API can expose sensitive data, putting your application and your users at risk. Always use HTTPS to encrypt data in transit, preventing anyone from snooping on the information being exchanged. Beyond that, you need to control who can access your API and what they can do. Implementing strong authentication methods like API keys or OAuth is a fundamental step in protecting your resources. Regularly checking your API for weaknesses helps ensure it remains a secure and trusted tool for your users.
Write Clear Error Messages
When something goes wrong, a vague error message is incredibly frustrating. A status code like '400 Bad Request' tells a developer that there's a problem with their request, but it doesn't explain what the problem is. This is where clear error messages come in. A good error response should be helpful, not mysterious. Providing clear error messages that include the status code, a simple message, and a description of the issue helps users quickly identify and fix the problem on their own. For example, instead of just "Bad Request," try "Invalid email format in 'email' field." This saves developers time and reduces their reliance on your support team.
How REST APIs Drive Workflow Automation
In any organization, work doesn't happen in a vacuum. It flows between different departments, teams, and software applications. A customer order might start in your e-commerce platform, move to your inventory system, trigger an action in your shipping software, and finally land in your accounting tool. The secret to automating these complex business processes is getting all those different systems to communicate effectively. This is where REST APIs come in, acting as the universal translators that allow your software to work together seamlessly.
By using REST APIs, you can build bridges between otherwise disconnected applications. This connectivity is the backbone of modern workflow automation. It allows you to design and implement end-to-end processes that run automatically, reducing manual effort, minimizing errors, and speeding up operations. Instead of employees manually transferring data from one system to another, APIs handle the exchange instantly and accurately. This frees up your team to focus on more strategic work while the technology handles the repetitive tasks. For businesses aiming for digital transformation, mastering the use of APIs in automation isn't just an option; it's a fundamental requirement for building a more efficient and responsive organization.
Connect Your Systems with REST APIs
At their core, REST APIs are designed to help different computer systems and applications talk to each other smoothly over the internet. They use a set of standard, web-based rules that almost any application can understand, making them a universal solution for integration. Think of an API as a messenger that takes a request from one application, delivers it to another, and then brings back the response. This simple but powerful mechanism allows you to connect your CRM, ERP, marketing platforms, and custom databases.
This ability to create a network of interconnected systems is what makes true workflow automation possible. For example, when a sales representative marks a deal as "closed-won" in your CRM, a REST API call can automatically create a new project in your project management tool and generate the first invoice in your accounting software. There’s no need for manual data entry, which saves time and prevents costly mistakes.
Use REST APIs in Low-Code Platforms
REST APIs are a perfect match for low-code platforms because they make powerful integrations accessible to everyone, not just professional developers. These platforms provide visual, drag-and-drop interfaces where an API call is just another building block in your workflow. You can connect to a service, pull the data you need, and send it somewhere else without writing a single line of complex code. The platform handles all the technical details behind the scenes.
This approach empowers business users and citizen developers to build their own automated solutions. An HR manager could design an employee onboarding workflow that uses APIs to create a new user account in the IT system, enroll the employee in the payroll platform, and assign initial training modules in the learning management system. APIs make it easier for programs to work together without you needing to understand the intricate details of how each one functions internally.
Related Articles
- API Management Without Code
- Top 10 Tips To Create A Secure Workflow Automation Using AI
- Secure Workflow Automation & Hyperautomation Solutions | FlowWright, Inc.
Frequently Asked Questions
What's the simplest way to understand the difference between REST and other APIs like SOAP? Think of it like sending a package. REST is like using a standard, lightweight courier service that everyone knows how to use; it's flexible and gets the job done efficiently. SOAP is more like using a specialized armored truck service. It has very strict rules, heavier packaging (XML), and more overhead, which can make it slower but is sometimes required for older or highly specific systems. For most modern web applications, REST's simplicity and performance make it the better choice.
Why is it so important for an API to be "stateless"? Statelessness makes an API more reliable and easier to grow. Because the server doesn't have to remember anything about you from one request to the next, any server in a group can handle your request. This means if one server gets busy or goes down, your request can be instantly rerouted to another without any problems. It simplifies the whole system and is a key reason why REST APIs can handle huge amounts of traffic.
Do I need to be a developer to use REST APIs for automation? Not at all. While developers build the APIs themselves, you don't need to write code to use them for automation, thanks to low-code platforms. These platforms provide visual interfaces where you can connect to an application's API with just a few clicks. You can then drag and drop that connection into a workflow, telling the system to pull or send data without ever touching the underlying code.
When should I use PUT versus PATCH to update data? It comes down to whether you are replacing something entirely or just making a small change. Use PUT when you want to replace a whole resource with a new version. For example, if you're updating a user's profile, a PUT request would require you to send all the user's information (name, email, address) again. Use PATCH for partial updates, which is more efficient. With PATCH, you could send just the user's new address, and the server would only change that one field.
My company uses many different software tools. How do APIs help connect them all? APIs act as the universal translators between all your different software applications. Each tool, whether it's your CRM, accounting software, or marketing platform, can expose an API that allows other systems to access its data and functions in a controlled way. An automation platform can then use these APIs to create workflows that move information between tools automatically, creating a single, unified process from otherwise disconnected systems.
