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.
Related
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 building a web app with Laravel for scheduling emails and when I was checking out the competitors, I noticed that one of them is using only one endpoint for all the requests and sending different payload in the POST request.
I thought of building my app's API the same way but I really don't find the use of this point.
I noticed that one of them is using only one endpoint for all the requests and sending different payload in the POST request.
It's a common approach to use when you want transport agnostic messaging. See, for example, SOAP.
When I drag an existing call to Autoresponder it generates a rule based on the method and URL. This works fine for REST APIs but not for APIs that are not based on the URL(like SOAP). Is there a way to make it respond based on the request body?
I'll explain the full use case. I have a .saz containing about 100 POST request to a SOAP API containing a repro for a bug in a application that I've created. I'm looking for an easy way to replay the communication that causes my app to crash.
You can use fiddler to respond with soap but because the URLs are the same for different calls, only one can be set up to respond at a time. After generating the rule create a .dat file that contains the soap response.
I am working with this third party service provider where i have to fetch / filter some data from them. The search filter parameters are complex in nature and contains too many filter params. I have tried to use querystring values and with querystring, i find it more difficult to send data since the data i have to send may contain an array of objects.
With JSON request body even with HTTP GET request, I find it extremely easy to process the request and did the testing using Insomnia REST client with ease. However POSTman REST client doesn't allow to send body parameters with GET request.
I have seen others using POST request to fetch / filter data from the api for the same purpose. POST HTTP request can be used to fetch data, but is it good from the technical standpoint? Is it recommended practice to send JSON request body values with GET request?
Not sure how much control you might have on the protocol or you have any middleware, but an HTTP GET usually doesn't have a body, I've even seen smart firewalls and hosting services strip any body by default. If you want to stay "close" to clean REST, you might consider adding a "/query" to your resource path and do a POST to that endpoint; it's a bit "RPC-ish" but not too bad. Another option would be to have a completely independent query service that could be using another protocol such as JSON-RPC.
I have a form that allows the user to send invites to others. The amount of invites is configurable by the user in the user interface, and could theoretically be infinite. The user needs to define an email address per invite.
When clicking 'send' it should ideally post one request to the server, wrapping all records in one bulk submit. Even though this is not truly RESTful (I heard), it seems favourable over sending possibly 50 separate requests. However, what would be the proper way to do this?
It gets tricky when one of the invites fails, due to a malformed email address or duplicate invites or so. It is fine to properly process the other valid requests, and provide errors on the invalid requests, but what response status code would one use for this?
Generally I try to use the JSONAPI request format. The errors would be in a top object called errors and would be an array consisting of multiple objects. The field key within an error object would point to the record index number (as received in the request) and field name of the error, i.e. "field": "/invites/0/email" for an error on the email field in the first received record.
The best solution I've seen to the "batch request" problem is Google Calendar's API. It is a RESTful API, and therefore there is a URL for every resource which you can manipulate using standard REST sematics (i.e. GET, POST, PUT, DELETE). But the API also exposes a "/batch" endpoint, which accepts a content-type of "mixed/multipart", and the request body contains several nested HTTP requests, each with their own headers, method, url and everything. The response is also one HTTP response with a content-type of "mixed/multipart" containing a collection of individual HTTP response, one response per request.
This advantage of this solution is that
1. It allows you to design your system in a RESTful manner, which we all know and love.
2. It generalizes well to any combination of HTTP requests that your system can deal with.
For more info see: https://developers.google.com/google-apps/calendar/batch