I'm trying to get allowed host limit for each volume. using the api in http://sldn.softlayer.com/reference/services/SoftLayer_Network_Storage
I always get "0" for the allowed host limit value.
How can I get the right value?
I ran the following Restful and it returns the proper values
https://api.softlayer.com/rest/v3/SoftLayer_Network_Storage/$StorageID/getAllowedHostsLimit
replace StorageId with the id of the object storage you want to get the allowed host limit
I just called this method http://sldn.softlayer.com/reference/services/SoftLayer_Network_Storage/getAllowedHostsLimit
Make sure you have enough permissions to see the storages
Regards
Related
I have a tracking number from Amazon that starts with TBA that I'd like to track via their API. I've seen their getPackageTrackingDetails endpoint but it takes an integer as input and I get an error when I try to use a TBA number on that endpoint. I know it is possible somehow, since AfterShip can do it (just enter a valid tracking number that starts with TBA). I cannot find in Amazon's docs how to do it and Amazon customer support doesn't know how to do it, either.
You have to distinguish between the packageNumber (which is an integer) and the trackingNumber (which is a string). When creating your shipment, you will get the packageNumber. With that number you can call getPackageTrackingDetails.
The Shipping-Api seems to be the right endpoint to use. See https://github.com/amzn/selling-partner-api-docs/blob/main/references/shipping-api/shipping.md#get-shippingv1trackingtrackingid
The getTrackingInformation operation accepts a tracking number as an input parameter.
Looking through the API documentation, there doesn't seem to be a good way to go from TBA number (if you can't just cut off those first three letters) to Package ID.
My order of operations on fixing this problem:
Chop the first three letters off the TBA variable you have, convert to integer, try it. Per Andrew Morton's comment.
What AfterShip may also be doing is going from the order ID. If the TBA is closely related to the order ID, the Amazon API will give you the information to go from Order ID -> Fulfillment Shipment -> Fulfillment Package -> Package ID. You could then use the Package ID to get your package information. So I'd look at Order ID's as well as Package ID's to see if you could convert one to another.
Given Stevish's comment, it's possible that the TBA can be cut off the TBA number and used as a package number if there is only one package in the order, but things get more complicated in other situations.
If you're working on a site that has the seller Order ID stored on your side, that seems to be the intent they have for getting it through the API.
I am trying to make a Get request against an API and the URL contains a lot of Guids.
How can set an unlimited URL limit to my IIS express in order to make this query.
Query example:
https://localhost:44329/api/user_collections/(7e9046ff-93ba-4f4f-a185-0330967e33b4,e88605f2-772f-493a-b9ee-1b561f45af57,e8796bef-cf53-47ca-85e7-1c683775c40f,2f795791-dfd7-469d-881b-217ad3aeb4f0,2f795791-dfd7-469d-881b-217ad3aeb4f0,e36c1106-e38d-40aa-816c-318e06bc9443,e36c1106-e38d-40aa-816c-318e06bc9443,dd07a986-a63a-4a8c-8f77-3944955ab5d4,46299c82-cbf8-4256-996b-4ac6ef975f09,46299c82-cbf8-4256-996b-4ac6ef975f09)
Turns out there’s a registry setting for indicating the maximum length of any individual path segment called “UrlMaxSegmentLength.” The default value is 260 characters. When our route value was longer than that, we’d get the 400 error.
The solution is to pass the value on the querystring rather than as a route value. Something to consider if you have route values that are going to be long. Of course, this isn’t a problem with routing, just that you can get into the situation pretty easily when you get into the habit of pushing parameters into the route. It might be nice in future versions of routing to have some sort of max length check when generating full route URLs so you can’t generate a path segment greater than, say, 256 characters without getting an exception.
I am using RAWG api to get names of the Games based on genre currently I am just testing the url requests and I could come with this code
https://api.rawg.io/api/games?limit=1&genre%20=%20action
But the problem here is I am getting bunch of information as json file, I just want the name of 5 games.
Can anyone help me :)
The API is pretty clear on how to call it (see the docs) and what it does return:
As you can see here, the calls always returns a json with count and results, where result is an array of Game which consists of more fields than the name.
However, you can limit the amount of games returned by using the page_size parameter, leaving you with: https://api.rawg.io/api/games?page_size=5&genre%20=%20action
I use CouchDB 1.5.0 and noticed a strange thing:
When I query some API action, for example:
curl -X GET "http://localhost:5984/mydb/_changes?limit=1"
I get the same result with limit=1 and with limit=0 and with limit=-55. In all cases is a one row from the start of list.
Although, PostgreSQL returns:
Zero rows when LIMIT 0
Message ERROR: LIMIT must not be negative when LIMIT -55
My question is mainly concerned with the API design. I would like to know your opinions.
It's a flaw or maybe it's good/acceptable practice?
This is how the _changes api is designed. If you do not specify the type of feed i.e long-poll, continuous etc the default is to return a list of all the changes in a single results array.
If you want a row by row result of the changes in the database specify the type of feed in the url like so
curl -X GET "http://localhost:5984/mydb/_changes?feed=continuous"
Another point to note that in the _changes api using 0 has the same effect as using 1 in limit parameter.
I cannot get the Flickr API to return any data for lat/lon queries.
view-source:http://api.flickr.com/services/rest/?method=flickr.photos.search&media=photo&api_key=KEY_HERE&has_geo=1&extras=geo&bbox=0,0,180,90
This should return something, anything. Doesn't work if I use lat/lng either. I can get some photos returned if I lookup a place_id first and then use that in the query, except then all the photos returned are from anywhere and not the place id
Eg,
http://api.flickr.com/services/rest/?method=flickr.photos.search&media=photo&api_key=KEY_HERE&placeId=8iTLPoGcB5yNDA19yw
I deleted out my key obviously, replace with yours to test.
Any help appreciated, I am going mad over this.
I believe that the Flickr API won't return any results if you don't put additional search terms in your query. If I recall from the documentation, this is treated as an unbounded search. Here is a quote from the documentation:
Geo queries require some sort of limiting agent in order to prevent the database from crying. This is basically like the check against "parameterless searches" for queries without a geo component.
A tag, for instance, is considered a limiting agent as are user defined min_date_taken and min_date_upload parameters — If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future).
My app uses the same kind of geo searching so what I do is put in an additional search term of the minimum date taken, like so:
http://api.flickr.com/services/rest/?method=flickr.photos.search&media=photo&api_key=KEY_HERE&has_geo=1&extras=geo&bbox=0,0,180,90&min_taken_date=2005-01-01 00:00:00
Oh, and don't forget to sign your request and fill in the api_sig field. My experience is that the geo based searches don't behave consistently unless you attach your api_key and sign your search. For example, I would sometimes get search results and then later with the same search get no images when I didn't sign my query.