assume I have an API that gives a JSON response that return an id and a name.
In a mobile application normally I would make an http GET response to get this data in a one time connection with the server and display the results in the app, however if the data changes over time and I want to keep listening to this data whenever it changes how is that possible ?
I have read about sockets and seen the socket_io_client and socket_io packages, but I did not get my head around it yet, is using sockets the only way to achieve this scenario ? or is it possible to do it in a normal http request ?
Thanks for your time
What you need is not an API but a Webhook:
An API can be used from an app to communicate with myapi.com. Through that communication, the API can List, Create, Edit or Delete items. The API needs to be given instructions, though.
Webhooks, on the other hand, are automated calls from myapi.com to an app. Those calls are triggered when a specific event happens on myapi.com. For example, if a new user signs up on myapi.com, the automated call may be configured to ask the app to add a new item to a list.
is using sockets the only way to achieve this scenario ? or is it possible to do it in a normal http request ?
Sockets is only one of the ways to achieve your goal. It is possible to do it using a normal http request. Here, for example, the docs explain how to update data over the internet using HTTP.
From the flutter docs:
In addition to normal HTTP requests, you can connect to servers using WebSockets. WebSockets allow for two-way communication with a server without polling.
You'll find what you need under the networking section.
You should also take a look at the Stream and StreamBuilder classes.
Related
Right now the app will need to detect whether a field from API got change or not
for example the api will return
{
successOrNot : false
}
when the field successOrNot become true, only then it will go to next page.
However the method that im doing right now is by using Timer.periodic, so it will call the api every 1 seconds, until the successOrNot become true then it will stop calling it. Is there another way on doing this since im afraid that it will affect the server because of api calling excessively.
You should use webSocket in this situation, sever will send message and client (flutter app) will listen to message from server, your current solution is ping the server by REST several times per minute, it maybe overloads the server in some case, e.g you have a lot of client but server resource is limited.
Link document about webSocket here: https://docs.flutter.dev/cookbook/networking/web-sockets
Beside websocket, you can also use SSE (Server Sent Events). But just like websockets, SSE require implementation on both server and client side. And depending on the situation both options may not be viable.
I need a mechanism to store and access request specific data in Akka HTTP. Is it possible without sending values around to each actor that is called from the route?
Let's say I want to log performance of all operations, including request id, so I'm able to search logs by request id. So when logging inside actor, it would be great to do something like Request.id.
Note that API does not implement session, since this is a specific service which runs behind main API (which is doing authentication etc).
Is there any library or built in way suitable for this?
Thanks in advance
I'm new to whole live data broadcast. I'm creating a website on laravel 5.1, and I need to get live data from a REST API, and after making some changes, broadcast the result to my own users.
I'm using pusher to broadcast data to my clients. and I figured, I should use Guzzle and/or CURL to get data from API. but the part I don't understand is how to get live data from API? Is there an option in guzzle that will keep the connection open continuously,or should I create a job to execute guzzle code every few seconds?
I know we use websockets to create a persistent connection between the server and clients to broadcast live data. but how to create a persistent connection between API server and my server to transfer the data?
Thank you friends in advance, appreciate any help :)
It depends on an API that you are using. If it's an usual REST API, then there are no options to make a "live" catching. Only pull the API periodically.
You API provider might support webhooks, websockets or some other technologies for push model. Depends on a provider, as I said before.
So I'm starting to use Redis and Socket.io to broadcast events to the client side. I'm using Laravel for the backend and will take advantage of their event functionality.
Based on a user's access level, I only want them to listen to certain channels. I figured I could dynamically set the channels they will listen to, but I was worried about whether or not they could use a debugging tool or the sort to change the channel they're listening to.
For example, maybe the page will load listening on 'channel-100', but can they alter the code so that it can listen to any other channel, like to 'channel-110'?
I am not sure I can help specifically with Socket.io, but I can tell you how we have approached that in our realtime system, and this may apply to your problem.
Clients can request to attach to a channel, so it's the inverse of what you suggested i.e. clients decide what they listen to, server's don't decide. See how channels attach.
Now to address your concern of which clients can access which channels then, your Laravel app should be issuing a token that specifies what rights it has. As your Laravel app is responsible for identity management and knows who the user is, it is always best positioned to have this up to date information at any time. So your client should request a token from your Laravel app, which is passed to your Socket.io server, which should in turn then apply rules to allow / disallow requests to join those channels. That way your Socket.io server does not need to have any business logic embedded from your system, and issuing tokens is easy in your app.
See how we made token authentication can work with your app.
I realise it's not a direct answer, but I hope it helps how you think about it architecturally.
Matt, co-founder, Ably: simply better realtime
I am writing a REST API providing CRUD operations on resources.
I'd like the users to be able to register to some resources changes and get the updates via server push. For the server push I will provide support for reverse ajax, hidden iframe and websockets. In order to be as REST as possible I created a Streaming resource which handles the registrations and the connection to the client:
Streaming resource:
URI uri : A GET against this URI refreshes the client representation of the resources accessible to this user.
bool WebSocket : Indicate if websocket is available on this server
bool ReverseXHR : Indicate if ReverseXHR is available on this server
bool HiddenIframe : Indicate if HiddenIframe is available on this server
Registration[] Registrations : The set of registration tasks.
OpenChannel : Open streaming channel from webserver to client. GET parameter type=(websocket|xhr|hiddeniframe)
CloseChannel : Close streaming channel from webserver to client. GET parameter type=(websocket|xhr|hiddeniframe)
A call of openchannel?type=websocket would open the websocket and start streaming the data of the registered values.
I've read many articles but I am still a bit confused. Can I still call my API REST after doing this? And if no (or yes) why?
Thank you for your help!
Firstly, always implement what makes sense to solve the problem you face. Conforming to a given architectural style provides specific benefits but this should not exclude pragmatic solutions to a given problem.
But having said that, it seems like you're using streaming of resource data as a way to "tunnel" information back & forth between the client and the server. I'm pretty new to this but it seems to me that the tunneling data goes against the uniform interface constraint in the REST architectural style. Tunneling over HTTP is one of criticism level against soap based services.