So, anyone used Delphi's REST library against Google's API (GMail in my case)?
So, anyone used Delphi's REST library against Google's API (GMail in my case)?
Seems I can only do about one request per ~500ms on average, not very fun when you want to show a list of email headers...
Am I doing something retarded or do I need to go for batch requests?
Seems I can only do about one request per ~500ms on average, not very fun when you want to show a list of email headers...
Am I doing something retarded or do I need to go for batch requests?
I'm just getting the id's, I tried setting "fields" in the request to include "snippet" but no dice. I guess I'm being dumb :)
ReplyDeleteHere's what I'm doing:
ReplyDeleteRESTClient.BaseURL := 'https://www.googleapis.com/gmail/v1/users/me/';
RESTClient.Authenticator := OAuth2Authenticator;
RESTRequest.Resource := 'messages';
RESTRequest.Execute;
Log(Format('%d %s', [RESTResponse.StatusCode, RESTResponse.StatusText]));
Log(RESTResponse.Content);
if RESTResponse.StatusCode <> 200 then
exit;
list := RESTRequest.Response.JSONValue as TJSONObject;
messages := list.Values['messages'] as TJSONArray;
Each entry in "messages" contain just "id" and "threadid" fields.
Ah, seems I didn't understand how RESTRequest.AddParameter worked. That might be why.
ReplyDeleteLet us know.
ReplyDeleteOr perhabs the json parsing. Which parameter of the messgaelist endpoint coukd switch subject on or off?
ReplyDeleteCan you see all info in the log ... do you see the subject in the raw content?
ReplyDelete200 HTTP/1.1 200 OK
ReplyDelete{
"messages": [
{
"id": "14814a608e08330c",
"threadId": "14814967c1cd049e"
},
{
"id": "14814a4f5438e0a7",
"threadId": "14814967c1cd049e"
},
{
"id": "14814a0dbd8ae118",
"threadId": "14814967c1cd049e"
},
and so on... so even though I got the "fields" filtering to work, fields only filter away stuff it seems, and given that the raw data isn't there, no dice :(
FWIW here's using threads.list instead of messages.list:
ReplyDelete200 HTTP/1.1 200 OK
{
"threads": [
{
"id": "14814967c1cd049e",
"snippet": "",
"historyId": "232178"
},
{
"id": "14812f1c4f3b265b",
"snippet": "",
"historyId": "231990"
},
I don't understand why they do not provide a call where you can get a list of messages with subject, but they seem to do. So the only way to get to the subject text in a reasonable time would be to use threads to get them based on the message ids.
ReplyDeleteRoland Kossow I was very surprised considering it's what I imagine a very frequent use case. Perhaps it's tied to the usage metering.
ReplyDeleteIn any case I was even more surprised to see that the REST stuff in Delphi doesn't do persistent http connections. I mean http 1.1 isn't some newfangled thing and multiple REST requests surely is a common use case?!
Roland Kossow Btw thanks for the input.
ReplyDeleteAsbjørn Heid eh ... you are welcome for me not helping :-)
ReplyDeleteConsidering the keeping open of connections: I thought the server would be responsible to set a keep-alive setting and depending on that the connection would stay open. I usually experience my first request to be a lot slower than the following ones. Nevertheless in case of google even when you use their APIExplorer you have a roundtrip time of 500ms so it might be the bottleneck on their side? (Hm hard to believe though.)
The Delphi REST framework seems to introduce a framework abstraction, so it should be possible to extend it to use other libraries or (if it can be done on behalf of the client) to keep the connection alive (persistent) - do you have the source of the framework? Perhabs we should establish a open-closed-source study group. Any others interested?
Roland Kossow The TRESTRequest.Execute explicitly disconnects the HTTP client once it's done, so doesn't really matter what the server says.
ReplyDeleteYes the HTTP client part is nicely abstracted, but I need to look more closely to see how to work around the explicit disconnect. Unfortunately I'm exceptionally short on time on this project, so will have to wait a wee bit.