Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove container style links #7787

Merged
merged 1 commit into from
Jan 14, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 11 additions & 5 deletions modules/ROOT/pages/rest-alternatives.adoc
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
// Copyright (c) 2020,2021 IBM Corporation and others.
// Copyright (c) 2020,20225 IBM Corporation and others.
// Licensed under Creative Commons Attribution-NoDerivatives
// 4.0 International (CC BY-ND 4.0)
// https://creativecommons.org/licenses/by-nd/4.0/
Expand All @@ -13,12 +13,18 @@
:page-type: general
= Alternatives to REST for client-server communications

Although REST is a widely adopted pattern for communications among microservices, Open Liberty supports alternative options that might be better suited for some application scenarios. These alternatives include GraphQl, gRPC, and WebSocket.
Although REST is a widely adopted pattern for communications among microservices, Open Liberty supports alternative options that might be better suited for some application scenarios. These alternatives include GraphQL, gRPC, and WebSocket.

Despite the ubiquity of REST-style communication among microservices, REST comes with tradeoffs in capability and performance that can make it a less than ideal solution for some use cases. Issues such as over-fetching and under-fetching of data, lack of real-time communication, and tight coupling between client and server can lead to performance and maintenance concerns for certain types of applications. To address these issues, developers can use alternative protocols and technologies that specifically address the shortcomings of REST.
REST comes with tradeoffs in capability and performance that can make it a less than ideal solution for some use cases. Issues such as over-fetching and under-fetching of data, lack of real-time communication, and tight coupling between client and server can lead to performance and maintenance concerns for certain types of applications. To address these issues, you can use alternative protocols and frameworks that specifically address the shortcomings of REST.

For example, xref:microprofile-graphql.adoc[GraphQL] is an open source data query and manipulation language for APIs that directly addresses problems with over-fetching and under-fetching of data that might occur with REST APIs. Similarly, the xref:web-socket.adoc[WebSocket] protocol enables real-time bidirectional communication between a server and one or more clients, which is not feasible in REST architecture. High-performance applications that require high throughput and low latency can benefit from the efficient data serialization and multiplexing capabilities that xref:grpc-services.adoc[gRPC] provides.
* xref:microprofile-graphql.adoc[GraphQL]: This open source data query and manipulation language for APIs directly addresses problems with over-fetching and under-fetching of data that might occur with REST APIs.
* xref:web-socket.adoc[WebSocket]: This protocol enables real-time bidirectional communication between a server and one or more clients, which is not feasible in REST architecture.
* xref:grpc-services.adoc[gRPC]: This framework provides efficient data serialization and multiplexing capabilities for high-performance applications that require high throughput and low latency. It also enables efficient communication between services and applications in various languages and platforms.

Ultimately, the framework you choose depends on the specific needs of your application, including factors like performance requirements, data complexity, and the technologies you're already using.
Ultimately, the framework that you choose depends on the specific needs of your application, including factors like performance requirements, data complexity, and the technologies you're already using.

== See also

link:/guides/#rest_alternatives[Guides: REST alternatives]

// assisted by watsonx with latest GenAI contribution: Granite-3-8b-instruct