When using Foursquare API, if I pass up to 6 categories id's in categoryId parameter, it works fine. But, if I pass 7 or more, Foursquare returns 500 internal server error, saying that their servers are down (see below). The fact is that the servers are up and the API docs don't say anything about categories limit. The specific query I'm using is this:
https://api.foursquare.com/v2/venues/search?v=20120321&ll=-19.879190%2C-43.927068&limit=50&intent=checkin&radius=500&categoryId=4d4b7105d754a06374d81259%2C4d4b7104d754a06370d81259%2C4d4b7105d754a06377d81259%2C4d4b7105d754a06375d81259%2C4d4b7105d754a06378d81259%2C4d4b7105d754a06379d81259&client_id=[MY_CLIENT_ID]&client_secret=[MY_CLIENT_SECRET]
If I add categories like 4d4b7105d754a06372d81259 and 4d4b7105d754a06376d81259 (all valid categories), the server starts to return 500 Internal Server Error. Is this a bug, or am I missing something?
I don't believe this is a URL size limit, since the entire URL with escaping is exactly 410 characters long when passing the 6 categories id's.
The error response is as follow:
HTTP/1.1 500 Internal Server Error
Date: Tue, 21 Aug 2012 18:19:48 GMT
Content-Length: 183
Content-Type: application/json
Connection: close
Server: nginx/1.2.1
{
"meta": {
"code": 500,
"errorType": "server_error",
"errorDetail": "Foursquare servers are experiencing problems. Please retry and check status.foursquare.com for updates."
},
"response": {}
}
I think this has been fixed — I tried a search with just shy of 30 categories and it seemed to work. No server error and I got a good sampling of venues from most of the categories.
Related
I'm trying to create device groups to eventually create a Job with this particular device group to send a reboot command to all the devices in it. I'm using the IoT Central API REST for this with the URL looking like this (which is how it is on their documentation): PUT https://{subdomain}.{baseDomain}/api/deviceGroups/{uuidCreatedByMe}?api-version=2022-07-31
The body on the request looks something like this:
{
description: `Pulses' group to be rebooted, created at ${DateTime.now().toISO()}`,
displayName: `Reboot group ${deviceGroupId}`,
filter: query,
}
And the query is very similar to this
SELECT * FROM devices WHERE $template = "templateId" AND $id IN ["deviceId1", "deviceId2"]
But for some reason, when I send the request, it responds with an error:
Request failed with status 500 and error: {
"code": "InternalServerError",
"message": "Something went wrong on our end. Please try again. You can contact support at https://aka.ms/iotcentral-support. Please include the following information. Request ID: requestId, Time: Tue, 06 Sep 2015 477:10:01 GMT.",
"requestId": "requestId",
"time": "Tue, 06 Sep 2022 16:10:01 GMT"
}
However, when I try to create a Job and get the list of device groups, this brings me all the device groups I have been attempting to create, but it doesn't let me see the number of devices and doesn't allow me to continue creating the Job. And then, I request through the REST API to delete such device group with one of the ids, and it deletes it just fine.
My question would be...
Is this related to the query or what exactly?...
Because according to their documentation this is a valid query
I can confirm that it is not supported yet, try to use ($id= '' OR $id = '') to work around now.
I am using the following API:
https://learn.microsoft.com/en-us/rest/api/compute/virtualmachines/delete
When trying to delete a VM which does not exist, I am given this response:
Response Code: 204
Headers-
cache-control: no-cache
expires: -1
pragma: no-cache
x-ms-correlation-request-id: 0bda7be7-6f2a-4202-9565-04d16c210606
x-ms-ratelimit-remaining-subscription-deletes: 14996
x-ms-request-id: 0bda7be7-6f2a-4202-9565-04d16c210606
x-ms-routing-request-id: WESTINDIA:20181223T044056Z:0bda7be7-6f2a-4202-9565-04d16c210606
Body: null
Shouldn't ideally a HTTP 404 be returned?
I suggest you take a look at Track asynchronous Azure operations to better understand the flow of execution when using Azure's management APIs.
As far as I understand, you are getting a 204 because the operation doesn't complete immediately. If you want to check the operation's state and end result, you need to query for it using methods described in the above link.
Update
After trying the operation on one of my subscriptions, looking at portal's activity log, it seems that the operation is being logged as "Succeeded". I'm afraid that the only way to know if a VM exists or not, is by trying to query for its info.
I also think, that in previous versions of the API a 404 was being returned in case the VM was not found, but for some reason it was changed (maybe because if it is not found then it already in a "deleted state").
Hope it helps!
I have an Application API wrapped in API Manager on Azure cloud service. For whatever reason when I send in a JSON payload of 1000 records or more (which translates to around 200k chars) the request is dropped. No trace, no logging just dropped but if I truncate the payload everything works as expected. If I send the same 1000 record payload into the underlying service (not through API Manager) all works as expected. Is there a request or return size limit when using APIM?
My underlying service was matching inner response codes and applying to overall return code if they were the same. My inner codes were all 404 "item not found". Azure API manager treats a 404 as an error and drops large payloads. This is per their support. On a small return payload it will return a code of 404 and the message but on a large payload it is dropped. Reason I was trying to return 404 is because each record in the return payload contains a status. If the status is mixed return 207 for mixed status but if they are all the same - 200 for found and 404 for not found the overall service was returning the internal status as the overall status. This was bad design. My payload consisted of a search for items that did not exist in the DB and therefore was returning 404 as overall status with messages for each record indicating "Not found". APIM was dropping the return response in favor of a generic 404 url not found response. Switched the internal service to return only 200 or 207 depending on outcome and all is right.
{
"ProcessId": "2",
"Code": 404,
"Message": "Could not resolve token.",
"Token": "#!!!#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
{
"ProcessId": "2",
"Code": 404,
"Message": "Could not resolve token.",
"Token": "#!!!#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
Overall return code was set to 404 and APIM dropped the response. I fixed this by setting overall return code to 200 in this case.
I have a Java application running in IBM Bluemix that is using a Cloudant (couchdb) database as a service. I have a document in that database which can't be deleted, as Cloudant returns a 409 conflict error when I try. However, when I query it for conflicts, it doesn't report any:
$ curl 'https://<user>-bluemix:<pass>#<host>-bluemix.cloudant.com/<dbname>/e4eca7af-cb27-4b1e-b738-31abcf880680?conflicts=true'
{
"_id": "e4eca7af-cb27-4b1e-b738-31abcf880680",
"_rev": "13887-a24ecaf2f6e628903e294b11e73d8ca8",
...[other stuff but no _conflicts section]
}
And when I try to delete it:
$ curl -i -X DELETE 'https://<user>-bluemix:<pass>#<host>-bluemix.cloudant.com/<dbname>/e4eca7af-cb27-4b1e-b738-31abcf880680?_rev=13887-a24ecaf2f6e628903e294b11e73d8ca8'
HTTP/1.1 409 Conflict
X-Couch-Request-ID: 02286a98ac
Server: CouchDB/1.0.2 (Erlang OTP/R14B)
Date: Wed, 15 Apr 2015 12:35:00 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 58
Cache-Control: must-revalidate
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff;
{"error":"conflict","reason":"Document update conflict."}
This is a document that has been deleted and recreated many times (which is how the _rev count got so high). Normally it works fine, but every now and then it gets into this conflict state. I have found that I can delete it through the Cloudant web interface, but seemingly not through the REST interface. But once I delete it, it works fine for a while and then the problem comes back.
So why does it say there's a conflict when I try to delete, but it won't tell me what the conflict is with the 'conflicts=true' parameter? I have also tried '_deleted_conflicts=true' and this also shows nothing.
How did it get into this state, and how can I prevent it happening in the future?
You need to say ?rev=, not ?_rev= to pass the revision correctly.
http://docs.couchdb.org/en/1.6.1/api/document/common.html#delete--db-docid
When you are deleting a document in Cloudant, you must supply the revision token as a "rev" parameter. You are passing in a "_rev" parameter. The error you are seeing is as if you haven't passed the revision at all.
See
https://docs.cloudant.com/api.html#delete36
Talked with our cloudant support folks, its actually rev= not _rev=.
I am trying to import existing mail content to a google group through apps.groups.migration API. The code is in C++ and the protolol is nakid HTTP. The program fails with HTTP error 500.
Following is the error response contents and header. What is wrong ?
{
"error": {
"errors": [
{
"domain": "global",
"reason": "backendError",
"message": "Backend Error"
}
],
"code": 500,
"message": "Backend Error"
}
}
Alternate-Protocol: 443:quic
Content-Length: 177
Content-Type: application/json
Date: Thu, 02 Jan 2014 06:50:10 GMT
Server: HTTP Upload Server Built on Dec 11 2013 18:21:10 (1386814870)
Backend Errors are a normal part of working with Google APIs and generally indicate that your application is sending data to Google to fast and needs to backoff some. See the details in the Group Migration API Limits document. Further details about implementing exponential backoff are offered in the Drive API docs.
You may want to take a look at the Google APIs Client Library for C++ rather than reinventing the wheel for these interactions.