I was wondering if it is possible to have a RESTful web service and a bidirectional communication with the clients and server.
In my case the state on the server can change, so the server should send a message to the clients to update themself. Perhaps that's totally against the RESTful idea.
Can I AJAX help me with this issue?
Thanks!
Not really possible under the standard http paradigm, but check out Comet for a possible workaround on that problem and there is alway polling.
The functionality you are after is treated by the concept of web sockets, but they are not mainstream yet.
To keep your solution RESTful you can have the clients poll your service. You can optimize any number of ways, like implementing a special method that lets clients query for changes given a timestamp, then the client just keeps track of when it last checked.
You should take a look at BOSH. BOSH is similar to Comet, but more specific, and I think, there are more reliable implementations.
Though, you will have problems serving multiple users at the same time if you want to use a standard REST service. You should think of some other implementation using nonblocking IO.
There are probably more questions about bosh. Of course, there are websockets now too, but if you need to serve old Browsers, you cannot rely on them.
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.
this is a general 'what technologies are available' question.
My company provides a web application with a RESTful API. However, it is too slow for my needs and some of the results are in an awkward format.
I want to wrap their restful server with a proxy/adapter server, so when you connect to the proxy you get the RESTful API I wish the real one provides.
So it needs to do a few things:
passthrough most requests
cache some requests
do some extra requests on the original server to detect if a request is cacheable
for instance: there is a request for a field in a record: GET /records/id/field which might be slow, but there is a fingerprint request GET /records/id/fingerprint which is always fast. If there exists a cache of GET /records/1/field2 for the fingerprint feedbeef, then I need to check the original server still has the fingerprint feed beef before serving the cached version.
fix headers for some responses - e.g. content-type, based upon the path
do stream processing on some large content, for instance
GET /records/id/attachments/1234
returns a 100Mb log file in text format
remove null characters from files
optionally recode the log to filter out irrelevant lines, reducing the load on the client
cache the filtered version for later requests.
While I could modify the client to achieve this functionality, such code would not be re-usable for other clients (different languages), and complicates the client logic.
I had a look at whether clojure/ring could do it, and while there is a nice little proxy middleware for it, it doesn't handle streaming content as far as I can tell - the whole 100Mb would have to be downloaded. Also it doesn't include any cache logic yet.
I took a look at whether squid could do it, but I'm not familiar with the technology, and it seems mostly concerned with passing through requests rather than modifying them on the fly.
I'm looking for hints where I might find the correct technology to implement this. I'm mostly language agnostic if learning a new language gets me access to a really simple way to do it.
I believe you should choose a platform that is easier for you to implement your custom business logic on. The following web application frameworks provide easy connectivity with REST APIs, and allow you to create a web application that could work as a REST proxy:
Play framework (Java + Scala)
express + Node.js (Javascript)
Sinatra (Ruby)
I'm more familiar with Play, of which I know it provides utilities for caching you could find useful, and is also extendable by a number of plugins.
If you are familiar with Scala, you could have a also have a look at Finagle. It is a framework build be Twitter's infrastructure team to provide protocol-agnostic connectivity. It might be an overkill for REST to REST proxy, but it provides abstractions you might find useful.
You could also look at some 3rd party services like Apitools, which allows to create a proxy programmatically (in lua). Apirise is a similar service (of which I'm a co-founder) that intends to do provide similar functionalities with a user-friendly UI.
Beeceptor does exactly what you want. It plugs in-between your web-app and original API to route requests.
For your use-case of caching a few responses, you can create a rule. That way it shall not hit the original endpoint.
The requests to original APIs can be mocked, and you can inspect response
You can simulate delays.
(Note: it is a shameless plug, I am the author of Beeceptor and thought it should help you and other developers.)
https://github.com/nodejitsu/node-http-proxy is looking useful - although I don't yet know if it can stream process for transcoding.
The problem
We are building an SOA with a RESTful approach to the services. Once the systems are in production we will have many clients consuming the interface including internal and 3rd party systems.
We would like to be able to consume and echo in the response information provided by the client application such as: -
Session Id - Could be a Java EE session id or anything client specific, this is useful for the support team and debugging client issues to trace them through all our systems.
Transaction Id - A unique identifier for the request that we can echo back to the client to aid the client in request/response correlation if they invoke the service asynchronously or if we implement an 202 Accepted style long running process.
Potential solutions
So sticking to the RESTful constraints would suggest we need to utilise HTTP to implement this and there are several options we could implement.
Pragma header - implement extension-pragmas for transaction-id, session-id, etc. This seems like purist of solutions as it utilises a standard HTTP header although I would be concerned it became a dumping ground for everything we can't be bothered to think about properly.
X-My-Header - custom headers for each field we require. May be stripped by proxies, not core HTTP so feels anti-rest
In query string or XML/JSON representations - Add the fields to all our resources. Because it's an operational parameter it feels like it should be provided as metadata rather than on a resource.
Cookies - use Cookie and Set-Cookie to hold custom key-values; useful in the case of session ids as most implementations use cookies already. Would have to re-send every time to support client side correlation which kind of defeats the point of using a cookie.
The answer
Is there any precedent for this? Are we mad? Is there something obvious I am missing in all my research? Does no-one actually care how they will support their services once they are deployed? Should I just shut up and go away?
I'm hoping someone can help.
P.S. sorry if this is a bit of an essay, the advice did say "be specific"....
Oh, this is a pain. I've been there too.
Well, the idea with metadata for transactions, sessions etc. is a good idea. For logging, at least.
The problem is to setup something that is compliant with various corporations policies and SOA infrastructure.
There is a tradeof between best design and maximum interopability in the case of HTTP.
The safe path is to encode the metadata in the message itself. Not very nice, and such a solution ends up looking a bit like SOAP where you have an envelope with headers for all messages.
I ended up using an X-header for information such as transaction id. However, as you mentioned, proxies/b2b-gateways etc. might strip headers, it's not obvious that you can retreive them with all appointed development frameworks, COTS applications etc. So if you do like this, you should avoid make the metadata mandatory to get a solution running - just "nice to have".
Cookies are nothing but pain. They might be annoying or sometimes even useful with browser interaction, but in a SOA scenario, it will be bad idea. Many things can go wrong and it's a pain to debug cross organisations.
I would also avoid using query strings along with POST or PUT data. It's possible according to the HTTP specs. but not when it comes to implementation in random framework.
You can use a GUID and let the client generate it and pass it as part of any request that starts the workflow/business process. This GUID can be used to correlate across multiple components participating in the workflow.
First off, I intend no hostility nor neglegence, just want to know people's thoughts. I am looking into bi-directional communication between client and server; client being a web application. At this point I have a few options: MS-proprietary duplex binding, from what I hear unreliable and unnatural: comet, and web sockets (for supported browsers).
I know this question has been asked in other ways here, but I have a more specific question to the approach. Considering web sockets are client-side, the client code sits in JavaScript. Is it really the intention to build a large chunk of an application directly in JavaScript? Why didn't W3C do this in web services? Wouldn't it be easier if we were to be able to use SOAP to provide a contract and define events along with the existing messaging involved? Just feels like the short end of the stick so far.
Why not make it simple and take advantage of JS dynamic nature and leave the bulk of code where it belongs....on the server?
Instead of
mysocket.send("AFunction|withparameters|segmented");
we could say
myServerObject.AFunction("that", "makessense");
and instead of
...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...
we could say
...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data...."); alert("Hello " + realData.FullName); }
...
HTML 5 took forever to take hold....did we waste a large amount of effort in the wrong direction? Thoughts?
Sounds to me like you've not yet fully grasped the concepts around Websockets. For example you say:
Considering web sockets are client-side
This is not the case, sockets have 2 sides, you could think of these as a Server and a Client, however once the connection is established the distinction blurs - you could then also think of the client and the server as "peers" - each can write or read in to the pipe that connects them (the socket connection) at any time. I suspect you'd benefit from learning a little more about HTTP works on top of TCP - WebSockets is similar / analogous to HTTP in this way.
Regarding SOAP / WSDL, from the point of view of a conversation surrounding TCP / WebSocket / HTTP you can think of all SOAP / WSDL conversations as being identical to HTTP (i.e. normal web page traffic).
Finally, remember the stacked nature of network programming, for instance SOAP/WSDL looks like this:
SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP
And WebSockets look like this
WebSocket
--------- (sits atop)
TCP
HTH.
JavaScript allows clients to communicate via HTTP with XMLHttpRequest. WebSockets extends this functionality to allow JavaScript to make arbitrary network I/O (not just HTTP), which is a logical extension and allows all sorts of applications that need to use TCP traffic (but might not be using the HTTP protocol) to be ported to JavaScript. I think it is rather logical that, as applications continue to move to the cloud, that HTML and JavaScript support everything that is available on the desktop.
While a server can do non-HTTP network I/O on behalf of a JavaScript client and make that communication available over HTTP, this is not always the most appropriate or efficient thing to do. For example, it would not make sense to add an additional round-trip cost when attempting to make an online SSH terminal. WebSockets makes it possible for JavaScript to talk directly to the SSH server.
As for the syntax, part of it is based on XMLHttpRequest. As has been pointed out in the other posting, WebSockets is a fairly low-level API that can be wrapped in a more understandable one. It is more important that WebSockets support all the necessary applications than that it have the most elegant syntax (sometimes focusing on the syntax can lead to more restrictive functionality). Library authors can always make this very general API more manageable to other application developers.
As you noted WebSockets has low overhead. The overhead is similar to normal TCP sockets: just two bytes more per frame compared to hundreds for AJAX/Comet.
Why low-level instead of some sort of built-in RPC functionality? Some thoughts:
It's not that hard to take an existing RPC protocol and layer it on a low-level socket protocol. You can't go the opposite direction and build a low-level connection if the RPC overhead is assumed.
WebSockets support is fairly trivial to add to multiple languages on the server side. The payload is just a UTF-8 string and pretty much every language has built-in efficient support for that. An RPC mechanism not so much. How do you handle data type conversions between Javascript and the target language? Do you need to add type hinting on the Javascript side? What about variable length arguments and/or argument lists? Do you build these mechanisms if the language doesn't have a good answer? Etc.
Which RPC mechanism would it be modeled after? Would you choose an existing one (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) or an entirely new one?
Once client support is fairly universal, then many services that have normal TCP socket will add WebSockets support (because it's fairly trivial to add). The same is not true if WebSockets was RPC based. Some existing services might add an RPC layer, but for the most part WebSockets services would be created from scratch.
For my noVNC project (VNC client using just Javascript, Canvas, WebSockets) the low-overhead nature of WebSockets is critical for achieving reasonable performance. Until VNC servers include WebSockets support, noVNC includes wsproxy which is a generic WebSockets to TCP socket proxy.
If you are thinking about implementing an interactive web application and you haven't decided on server-side language, then I suggest looking at Socket.IO which is a library for node (server-side Javascript using Google's V8 engine).
In addition to all the advantages of node (same language on both sides, very efficient, power libraries, etc), Socket.IO gives you several things:
Provides both client and server framework library for handling connections.
Detects the best transport supported by both client and server. Transports include (from best to worst): native WebSockets, WebSockets using flash emulation, various AJAX models.
Consistent interface no matter what transport is used.
Automatic encode/decode of Javascript datatypes.
It wouldn't be that hard to create a RPC mechanism on top of Socket.IO since both side are the same language with the same native types.
WebSocket makes Comet and all other HTTP push type techniques legible by allowing requests to originate from the server. It is kind of a sandboxed socket and gives us limited functionality.
However, the API is general enough for framework and library authors to improve on the interface in whichever way they desire. For example, you could write some RPC or RMI styled service on top of WebSockets that allows sending objects over the wire. Now internally they are being serialized in some unknown format, but the service user doesn't need to know and doesn't care.
So thinking from a spec authors POV, going from
mysocket.send("AFunction|withparameters|segmented");
to
myServerObject.AFunction("that", "makessense");
is comparatively easy and requires writing a small wrapper around WebSockets so that serialization and deserialization happens opaquely to the application. But going in the reverse direction means the spec authors need to make a much more complex API which makes for a weaker foundation for writing code on top of it.
I ran into the same problem where I needed to do something like call('AFunction', 'foo', 'bar') rather than serialize/de-serialize every interaction. My preference was also to leave the bulk of code on the server and just use the Javascript to handle the view. WebSockets were a better fit because of its natural support for bi-directional communication. To simplify my app development, I build a layer on top of WebSockets to make remote method calls (like RPC).
I have published the RMI/RPC library at http://sourceforge.net/projects/rmiwebsocket/. Once the communication is setup between the web-page and the servlet, you can execute calls in either direction. The server uses reflection to call the appropriate method in the server-side object and client uses Javascript's 'call' method to call the appropriate function in the client-side object. The library uses Jackson to take care of the serialization/deserialization of various Java types to/from JSON.
WebSocket JSR was negotiated by a number of parties (Oracle, Apache, Eclipse, etc) all with very different agendas. It's just as well they stopped at message transport level and left higher level constructs out. If what you need is a Java to JavaScript RMI, check out the FERMI Framework.