I need to implement a C/S structured system. Should I use RPC(like protobuf) or WebService(like SOAP based web service) as the communication infrastructure between the client and server?
How many angels dance on the head of a pin?
I prefer using SOAP calls, especially if I'm using visual studio because creating and consuming them is so easy and reliable.
I like REST calls if my client cannot easily handle SOAP calls and/or I have large volumes of calls or network limitations. The reasoning is that REST calls are harder to code and consume and less reliable when it comes to enforce interface consumption.
I try to balance software development time, reliability, and ease of consumption against scalability.
Related
I have a usecase where I have to collect user events and store it in Kafka. Is it efficient to directly use Kafka clients in mobile apps and websites to produce messages directly to Kafka instead of a middle layer. Is Kafka designed to handle millions of concurrent connections?
Technically you can do it. The main reason people do not do it, especially for mobile apps, is that it would rather be difficult to maintain a long-term evolution of the product, control its security or even its scale.
In the past years, Kafka Clients API has evolved dramatically (for the best but, it's still a change). It also includes authorization and authentication mechanisms, but there's not much freedom on what you can do with those. Kafka is not built upon a standardized protocol and technology-agnostic specification like JMS that could be thought as a bit more flexible.
Also, between major versions, compatibility is not guaranteed, as for most existing technologies. It may happen that you need to keep multiple server versions for a long time just because some mobile clients are still outdated and there's coupling to a specific client version, that itself is coupled to a specific server version.
On the other side and for the same reason, it could also happen that you would need to keep handling older versions of the messages schemas for a long time, just to keep older clients happy.
That's when HTTP and, more specifically, the API gateway pattern, comes into place.
HTTP APIs are easier to throttle, perform rate limiting, applying custom security policies, custom authentication/authorization strategies, etc. And they are based on a standard protocol that's used all over the Internet.
There are also advantages of using HTTP when you plan to have some partner integrations using your backend platform. As they can do it easily without changing the technology stack.
By not exposing Kafka to the outside clients, you can change the underlying technology stack later without impacting the clients. To be honest, although Kafka is a brilliant piece of technology, it's difficult to compete with HTTP for internet communication. Kafka actually provides a REST Proxy, an HTTP based client that could be possibly thought to be used for this sort of things.
I am currently working on a project made of many microservices that will asynchronously broadcast data to many possible client applications.
Additionally, client applications will be able to communicate with the system (i.e. the set of microservices) via a ReST Open-API
For broadcasting the data, my first consideration was to use a MOM (Message Oriented Middleware) such as AMQ.
However, I am asked to reconsider this solution and to prefer a ReST endpoint (over HTTP) in order to provide an API more "Open-API oriented".
I am not a big specialist of HTTP but it seems to me that main technologies to send asynchronous data from server to client are:
WebSocket
SSE
I am opening this discussion I order to get advices/feedback from other developers to help me to measure the pros & cons of this new solution. Among that:
is an HTTP technology such as SSE/WebSocket relevant for my needs
For additional information, here are a few metrics regarding the
amount of data to broadcast
considerable amount of messages per seconde
responsiveness
more than 100 clients listening for data
Thank you for your help and contribution
There's many different definitions of what people consider REST and not REST, but most people tend to agree that in practical terms and popular best practices REST services expose a data model via HTTP, and limit operations to this data model by either requesting the state of resources (GET), or updating the state of resources (PUT). From that foundation things are stacked on top of that.
What you describe is a pub-sub model. While it might be possible in academic terms to use REST concepts in a pub-sub architecture, I don't think that's really what you're looking for here.
Websocket and SSE are in most real-word situations do not fall under a REST umbrella, but they can augment an existing REST service.
If your goal is to simply create a pub-sub system that uses a technology stack that people are familiar with, Websockets are a really good choice. It's widely available and works in browsers.
I have plenty of times heard REST compared to SOAP, which has been debunked as an apples vs pears comparison (for example, here, on stackoverflow: SOAP vs REST (differences))
Although it is true that they are different things, what this flawed comparison tells me is that old SOAP systems would go hand in hand with a certain architectural style that people incorrectly labelled as SOAP since they were so tightly coupled.
Also, if REST is an architectural style, what is the communication protocol that is mainly used with it?
To sum it up,
REST is to the X protocol as the Y architectural style is to the SOAP protocol.
What are X and Y?
They are both ways of solving a similar architectural problem - loose coupling between services. We could add into this list pub/sub messaging, competing consumer pattern etc. In the case of SOAP and ReST they typically connect web services, SOAP to trigger business transactions brings in concrete implementation guidance and ReST for CRUD operations brings in a pattern only.
On the second point, ReST communication is typically implemented over HTTP, in theory it could run over other communication protocols although I am not aware of any in the mainstream.
You are correct they are two different web protocols, but they have different purposes.
REST is more modern and easier to understand and program. REST services usually expose a URL-like API. Requests are delivered in HTTP requests and payloads are commonly delivered as JASON structures. Many (if not most) public services use REST.
REST was born as way to access web services in a much simpler way than possible with SOAP.
SOAP is an older and more complex protocol, designed for a wide range of secure services. It is more reliable and more secure - eg its internal protocols can retry if messages are lost, and it also includes strong support for security and database transactions. SOAP can operate using HTTP, SMTP, TCP, UDP protocols, with message bodies being XML encoded.
Depending on the application REST or SOAP could still be the correct choice. They pose their own problems and have their advantages in specific situations. However REST is by far the most common choice, in a growing world of public web based services.
Therefore there is really no correct reply to:
REST is to the X protocol as the Y architectural style is to the SOAP protocol.
What are X and Y?
You might say:
REST is to straightforward data delivery services as
SOAP is to secure, transactional services (possibly also where complex state is being updated on the server).
Although I am sure many people will want to improve on this :-)
I like the APIs of the Retrofit and OkHttp rest/http libraries from Square. I am evaluating options for writing a server-side rest client. For each request to my SOAP-based web service, I have to consume another, restful web service, thus my need for a rest client.
My question is, are Retrofit and OkHttp suitable for server-side use in a highly concurrent web app, or are there likely to be issues, known or otherwise, stemming from these APIs having been designed for use primarily outside of the server-side?
Reading the documentation and perusing the code, nothing jumped out at me to indicate that these libraries would not be suitable. But I don't want to be a guinea pig either. Has anyone experienced any issues with server-side use under high load/concurrency? Had success? Anyone from the dev teams for those libraries care to comment? ;)
We use OkHttp on the Square Cash server and we haven't had problems.
Some of the default settings are not suitable for server side usage, for example, the maximum number of concurrent requests per host defaults to 5.
There is some discussion on this at https://github.com/square/okhttp/issues/4354.
In the microservices architecture world (using Spring Framework), Retrofit/Okhttp may not be a good fit as a REST client for inter-service communication. Using WebClient/RestTemplate will have at least the below advantages over using retrofit for the same purpose:
RestTemplate/WebClient can be easily configured to make use of client-side load balancing (Ribbon), thereby requests can be rotated among various instances or another microservice.
Hystrix can be easily configured with RestTemplate, thereby increasing the fault tolerance (circuit breaker pattern) of the overall system w.r.t inter-service communication.
Service discovery can be easily configured using Eureka or Consul, thereby the client need not know the host/port/protocol of the target web service. All we need is to enable the discovery client.
Alternatively, you can also explore Feign, which is a declarative web service client similar to retrofit, but with all the advantages of RestTemplate.
You can also have a loot at the following article:
https://www.javacodemonk.com/retrofit-vs-feignclient-on-server-side-with-spring-cloud-d7f199c4
Why are RESTful HTTP services so popular even in backend communications nowadays, except that it is a standard and simple?
I would never choose HTTP-REST for back-ends that require low latency and/or high throughput, mainly because:
HTTP uses a one-way request-response paradigm, that is not a full-duplex streaming.
HTTP implies packet-length and other information which is an overhead.
I can see RESTful web-services in many open-source projects, claiming that they are for low latency, high throughput. As an example, it is quite popular to create RESTful micro services, embed light-weight http-servers into server-side applications.
As an alternative I could use WebSockets (via HTTP upgrading of course) over TCP.
I am aware how HTTP works under the hood as well as a lower layer TCP. But please explain, except that HTTP-REST is a buzzword and simple that's why you should use one, any other advantages?
RESTful HTTP is a well established technology whereas WebSockets only became a W3C recommendation during summer 2014.
On one side, it takes some time until new technologies make their ways into products because people have to adopt to new technologies and very often you also do not want to rewrite your product just to have WebSockets.
On the other side, and more importantly, RESTful HTTP and WebSockets are completely different technologies. RESTful HTTP is stateless so you can build highly scalable applications. WebSockets on the other hands are bidirectional so both end, server and clients, can trigger communication. So at the end your decision should be based on the scenario. There have been cases in the past where RESTful HTTP was the perfect solution and so will it be still today. On the other hand scenarios that require real-time communication or server driven events will profit from WebSockets.
But the important thing: from now on you have a choice!