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
Related
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.
We are successfully sending data for new, changed, and removed events to Google Calendar from a Scala app using Spray HTTP. However, we are currently sending one event per request, and this becomes very inefficient when there are multiple events for the current user. In these cases we would like to send batched data, as described here:
https://developers.google.com/google-apps/calendar/batch
The documentation begins with:
A batch request is a single standard HTTP request containing multiple
Google Calendar API calls, using the multipart/mixed content type.
Within that main HTTP request, each of the parts contains a nested
HTTP request.
Since we are already using spray http we would like to use its support for multipart/mixed requests (spray.http.MultipartContent) but it isn't clear that this is possible since the parts must consist of one or more spray.http.BodyPart instances and there doesn't seem to be a way to turn a spray.http.HttpRequest into a BodyPart.
Has anyone successfully done this? We are also taking a look at the Google API Client for Java but would rather not go down that path if there is a more Scala-friendly way to do it.
I have a BizTalk application where I have exposed schema as a RESTful web service, which calls another REST service. I am able to successfully handle GET, DELETE request.
Is there a way to handle POST request without writing a pipeline component to serialize the POST request to a schema?
Also, the application may have to handle several POST calls, so will it be possible to serve this from one single receive location and then filtering the request on the send port?
Please let me know if any more details are required.
So, here's the thing. You're mixing together some things that technically have nothing to do with each other.
For instance, a Plain Old Xml (POX) service, usually a POST, does not 'expose' a Schema in the way a SOAP service does. It just takes whatever content is POSTed to it.
Following that, serialization/deserialization is also a concept more related to SOAP that POX or REST.
So...
Yes, but what exactly are you doing?
Yes. A plain http endpoint can accept any content type. Once it's over the wire, all the normal BizTalk processing rules apply.
I have a COTS application(PLM application) which has provided few SOAP APIs to access. Since this SOAP API is highly complex, we are developing a easy to use REST wrapper service. Before invoking any API in my COTS application, authentication API needs to be invoked. In my REST wrapper web service, I have a login resource which invokes COTS SOAP login API. To keep things simple for my API users, I store the logged in user details in user session. In every other REST resoruces, I retrieve the session and check whether session has user details. If yes, I proceed and invoke the SOAP API. if not, I return proper HTTP status code. I use Apache CXF for service and client. I mandate my APIusers to maintain the session in the client like this
WebClient.getConfig(client).getRequestContext().put(Message.MAINTAIN_SESSION,
Boolean.TRUE);
In every REST tutorials, it said REST is stateless. I am doubtful whether what I am doing is correct as per REST standards. Please suggest. Thanks
Basically the idea of REST is a stateless interface. However it is common practice to use some kind of authentication for API calls since most of the time not all resources should be public (e.g. the timeline of a twitter user over the twitter API)
Therefore it is ok if you do some kind of authentication and validate a session on further requests (or maybe authenticate with every single request, e.g. with HTTP Basic Access Authentication) to check if access should be granted.
Not part of this and not the idea of a RESTful API would be to store complex session information that would really make the whole thing stateful. This for example includes storage of information of an older request for processing together with one following later.
client.getRequestContext().put(Message.MAINTAIN_SESSION, Boolean.TRUE)
This code causes cookies to be maintained in that specific client only.
If you want those cookies be available in another client, it needs to be programmed.
And if the second client receives additional cookies and you want those cookies available in the first client too, how is that possible?
I need something like a root client that maintains cookies of all sub clients. All cookies must be shared among all clients. Like a shared cookie repository for all clients. Does anyone know how to achieve this?
We have a Public REST application which has a lot of GET's from the clients . We have a way to track the POST calls but we do not have a way to track where the user has come for the GET calls .
Our intention is to have some client specific business rules if we are able to decide where the call has come from ?
Returning different responses to a GET based on where the request comes from is not a great idea. Could you not POST the tracking id to an endpoint and have it redirect to a GET of ResourceA for this client and ResourceB for another client.
If you only want to track the GET requests then you could use cookies to identify the client. However, I would not recommended using the cookies to drive business logic.