under some circumstances, a request for the geocoder API in which a ParsedRequest object is requested (via the responseattributes parameter), does not contain a ParsedRequest object in the response. To reproduce (app id and code are omissis):
curl https://geocoder.api.here.com/6.2/geocode.json\?jsonattributes\=1\&searchtext\=marghera+Venezia+Veneto+Italia\&language\=it-IT\&maxresults\=1\&app_id\=xxx\&app_code\=xxx\&responseattributes\=mq%2Cmt%2Cpr
matches correctly as a district, but the expected ParsedRequest object is not present in the response
Conversely, A ParsedRequest object is present as expected if in the previous request we change “marghera” to “san+marco”:
curl https://geocoder.api.here.com/6.2/geocode.json\?jsonattributes\=1\&searchtext\=san+marco+Venezia+Veneto+Italia\&language\=it-IT\&maxresults\=1\&app_id\=xxx\&app_code\=xxx\&responseattributes\=mq%2Cmt%2Cpr
This time it matches correctly as “street” and the ParsedRequest object is present in the response as expected.
From this sample alone it seems that when the match is a district, the ParsedRequest object is not being populated. I've not yet tried with other district samples.
The documentation unfortunately does not mention it, but ParsedRequest will be returned for Street- and Housenumber level responses only.
Your first example "Marghera, Venice, Veneto, Italy" is a district level result, hence no ParsedRequest in the reponse.
https://developer.here.com/documentation/geocoder/topics/example-geocode-parsedrequest.html
Related
How do I get the response object from call-with-input-request when the HTTP status is >= 300?
The docs say this about call-with-input-request:
Returns three values: The result of the call to reader (or #f if there is no message body in the response), the request-uri of the last request and the response object. If the response code is not in the 200 class, it will raise a condition of type (exn http client-error), (exn http server-error) or (exn http unexpected-server-response), depending on the response code. This includes 404 not found (which is a client-error).
This means that call-with-input-request signals a non-continuable condition, which (as far as I understand) means that the function does not return, and I cannot get access to the response object that would otherwise be returned. Therefore I don't see how I can actually get access to the response object corresponding to this request.
I still want to be able to inspect the response, even if its status is in the 30x-50x range. For example, I want to be able to print the HTTP reason string, or log it for debugging later. How can I achieve this?
If you trigger the exception from the REPL, you can inspect it with the ,exn comma-command. Then you'll notice the condition has a response property which is a contains the status code, headers etc.
The docs could be improved in this regard I'm sure. Perhaps you have a suggestion where to put this? The problem is that the exact contents of the condition object depend on where the condition was thrown, so not all properties will always be available.
I am currently using some website to read some useful data. Using the browser's Inspect>Network I can see this data comes from JSON RPC requests to (https://bsc-dataseed1.defibit.io/) the public available BSC explorer API endpoint.
This requests have the following format:
Request params:
{"jsonrpc":"2.0","id":43,"method":"eth_call","params":[{"data":"...LONGBYTESTRING!!!","to":"0x1ee38d535d541c55c9dae27b12edf090c608e6fb"},"latest"]}
Response:
{"jsonrpc":"2.0","id":43,"result":"...OTHERVERYLONGBYTESTRING!!!"}
I know that the to field corresponds to the address of a smart contract 0x1ee38d535d541c55c9dae27b12edf090c608e6fb.
Looks like this requests "queries" the contract for some data (but it costs 0 gas?).
From (the very little) I understand, the encoded data can be decoded with the schema, which I think I could get from the smart contract address. (perhaps this is it? https://api.bscscan.com/api?module=contract&action=getabi&address=0x1ee38d535d541c55c9dae27b12edf090c608e6fb)
My goal is to understand the data being sent in the request and the data given in the response so I can reproduce the data from the website without having to scrape this data from the website.
Thanks.
The zero cost is because of the eth_call method. It's a read-only method which doesn't record any state changes to the blockchain (and is mostly used for getter functions, marked as view or pure in Solidity).
The data field consists of:
0x
4 bytes (8 hex characters) function signature
And the rest is arguments passed to the function.
You can find an example that converts the function name to the signature in this other answer.
I don't see nextSyncToken in the response. I followed the doc(https://developers.google.com/calendar/api/guides/sync) and paginated using nextPageToken but I couldn't see the nextSyncToken on the last page.
API Used: GET /calendars/primary/events?maxResults=10&singleEvents=true&pageToken=********
I don't know whether if I miss anything here. Could anyone help me with this?
I have seen from the response link on the other answer comment that you are using orderBy on the request.
This is why the nextSyncToken is not showing up.
As mentioned on the documentation on Events: list -> Parameters -> syncToken:
Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contain only entries that have changed since then. All events deleted since the previous list request will always be in the result set and it is not allowed to set showDeleted to False.
There are several query parameters that cannot be specified together with nextSyncToken to ensure consistency of the client state.
These are:
iCalUID
orderBy
privateExtendedProperty
q
sharedExtendedProperty
timeMin
timeMax
updatedMin
If the syncToken expires, the server will respond with a 410 GONE response code and the client should clear its storage and perform a full synchronization without any syncToken.
Learn more about incremental synchronization.
Optional. The default is to return all entries.
You should remove the orderBy from the request to get the syncToken
Could you please provide the response from gcalendar API? It's hard to say more without detail information. I event don't know which language are you using.
Try to use a vendor library to sort that out:
a) https://packagist.org/packages/google/apiclient (for PHP)
b) https://www.npmjs.com/package/google-calendar (for JavaScript)
and/or
Try to use alternative endpoint: GET https://www.googleapis.com/calendar/v3/calendars/calendarId/events.
The Here Batch Geocoder API indicates that the responseattributes request parameter can be used. I'm interested in getting geocode quality results back from a batch geocode file.
In the Response Attribute switches documentation it indicates that the default options would be On by default: matchQuality, matchType. But I'm not clear on how this actually gets returned from the batch geocoding API. It sounds like these attributes would be returned in the response, and in the API Explorer for the standard geocoder API it does appear that these are returned in the JSON response.
But the Batch Geocoder API returns an XML response, and then ultimately a collection of files including a final data file. In the Batch Geocoder API explorer, the sample XML response does not include either of those default fields.
At one point the batch geocoder demo credentials listed on the Here documentation worked, and I was able to pull back a small sample results file. I did not see those default responseattributes columns on any of the downloaded files, either.
For the Batch Geocoder API, is there a way to get back information about the quality of the geocoded address, matchQuality, matchType, etc?
The responseattributes parameter enables the additional response attributes to be includable with results, e.g. set it to: responseattributes=all
The outcols parameter attributes then define which ones you get and where.
I use the following request a lot to include scores for results analysis:
http://batch.geocoder.cit.api.here.com/6.2/jobs?action=run&app_code=[your-app-code]&app_id=[your-app-id]&gen=8&header=true&indelim=|&outdelim=|&outcols=displayLatitude,displayLongitude,navigationLatitude,navigationLongitude,mapViewTopLeftLatitude,mapViewTopLeftLongitude,mapViewBottomRightLatitude,mapViewBottomRightLongitude,locationLabel,houseNumber,street,district,city,county,state,postalCode,country,relevance,matchLevel,matchType,matchCode,mapReferenceId,responseAdditionalData,addressAdditionalData&addressattributes=all&locationattributes=all&responseattributes=all&maxresults=5&outputcombined=true&mailto=[yourname#domain.com]
It turns out that when you define the output columns for a batch geocode request, you can also list "Address Match Information" fields which provide the information I'm looking for: https://developer.here.com/rest-apis/documentation/batch-geocoder/topics/data-output.html
These fields are entered in the requset query parameters and then showed up on the resulting output data file that was downloaded.
I'm still not sure what the responseattributes parameter does then on the batch geocoder, or if it's even relevant.
Let's say you want to get list of users by calling GET to api/users, but currently the table was truncated so there are no users. What is the proper response for this scenario: 404 or 204?
I'd say, neither.
Why not 404 (Not Found) ?
The 404 status code should be reserved for situations, in which a resource is not found. In this case, your resource is a collection of users. This collection exists but it's currently empty. Personally, I'd be very confused as an author of a client for your application if I got a 200 one day and a 404 the next day just because someone happened to remove a couple of users. What am I supposed to do? Is my URL wrong? Did someone change the API and neglect to leave a redirection.
Why not 204 (No Content) ?
Here's an excerpt from the description of the 204 status code by w3c
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.
While this may seem reasonable in this case, I think it would also confuse clients. A 204 is supposed to indicate that some operation was executed successfully and no data needs to be returned. This is perfect as a response to a DELETE request or perhaps firing some script that does not need to return data. In case of api/users, you usually expect to receive a representation of your collection of users. Sending a response body one time and not sending it the other time is inconsistent and potentially misleading.
Why I'd use a 200 (OK)
For reasons mentioned above (consistency), I would return a representation of an empty collection. Let's assume you're using XML. A normal response body for a non-empty collection of users could look like this:
<users>
<user>
<id>1</id>
<name>Tom</name>
</user>
<user>
<id>2</id>
<name>IMB</name>
</user>
</users>
and if the list is empty, you could just respond with something like this (while still using a 200):
<users/>
Either way, a client receives a response body that follows a certain, well-known format. There's no unnecessary confusion and status code checking. Also, no status code definition is violated. Everybody's happy.
You can do the same with JSON or HTML or whatever format you're using.
I'd answer one of two codes depending on runtime situation:
404 (Not Found)
This answer is pretty correct if you have no table. Not just empty table but NO USER TABLE. It confirms exact idea - no resource. Further options are to provide more details WHY your table is absent, there is couple of more detailed codes but 404 is pretty good to refer to situation where you really have no table.
200 (OK)
All cases where you have table but it is empty or your request processor filtered out all results. This means 'your request is correct, everything is OK but you do not match any data just because either we have no data or we have no data which matches your request. This should be different from security denial answer. I also vote to return 200 in situation where you have some data and in general you are allowed to access table but have no access to all data which match your request (data was filtered out because of object level security but in general you are allowed to request).
If you are expecting list of user object, the best solution is returning an empty list ([]) with 200 OK than using a 404 or a 204 response.
definitely returns 200.
404 means resource not found. But the resource exists. And also, if the response has 404 status. How can you know users list empty or filled?
'/users' if is empty should return '200'.
'/users/1' if the id is not found. should return 404.
It must 200 OK with empty list.
Why: Empty table means the table exists but does not have any records.
404 Not Found means requested end point does not exist.