I can currently issue the following request: https://api.coinbase.com/v2/prices/spot?currency=USD and receive a json response with the current (spot) price of BitCoin (BTC).
What I want is to retrieve that information for Ether (ETH). I note that the HTTP request that I am using does not specify BTC, it just defaults to that.
I have reviewed the Coinbase API without success in locating an answer.
I was just wondering if anyone is aware of an HTTP request to obtain that data, or if this request is not currently supported via HTTP.
tia
The Coinbase API docs, https://developers.coinbase.com/api/v2#get-spot-price shows the following URI structure for getting the spot price for Bitcoin (BTC) or Ethereum (ETH), which is different from what you have posted.
https://api.coinbase.com/v2/prices/:currency_pair/spot
The part of the url indicated as :currency_pair is a string containing
the symbol for the coin, a hyphen and then 'USD', such as BTC-USD or ETH-USD.
I am able to get BTC and ETH spot prices from the api with the following:
https://api.coinbase.com/v2/prices/BTC-USD/spot
https://api.coinbase.com/v2/prices/ETH-USD/spot
Related
I am attempting to use the endpoint https://firestore.googleapis.com/v1/{parent=projects/*}/databases with more data needed per the documentation on Google's docs.
The goal is to be able to make this request with a standard http utility such as cURL.
I have attempted performing the request manually through the GUI with the Chrome network tab open, and I saw a request being made: https://firebasedatabase.clients6.google.com/v1beta/projects/XXXXXXXXXX/locations/us-central1/instances?databaseId=my-database&validateOnly=true&alt=json&key=secretkey
Per trial and error on another endpoint, I have found that the key parameter can be replaced with a Bearer Auth token in the header. Other than that I am at a dead end.
We're building a backend with a number of APIs. What should be the ideal range of HTTP codes that I should be using?
I've gone through https://en.wikipedia.org/wiki/List_of_HTTP_status_codes and they give a list such as:
1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error
But since I want to implement my own status codes for various purposes such as missing email, I want to name the response accordingly.
So, according to me, a missing email response should trigger a 4xx response as it's a client error. What I'm trying to understand is that should I look for the first open slot such as #419 or should I begin to number the HTTP codes after #451?
You shouldn't use any custom codes at all - they might conflict with future standardization.
If you think you have a use case for a new code that is of general use, propose it in the right place (the HTTP Working Group).
If you just need something specific to your application, use a 400 (in this case), and provide additional information in the response body.
I am having trouble retrieving isochrones for public transport using the HERE Maps API.
Specifically, we are using the public transport API with isochrone search feature as described here:
https://developer.here.com/rest-apis/documentation/transit/topics/resource-isochrone-search.html
When we make a request, and use the key allocated to us, we get a 403 permissions error.
If we use the API Explorer/Playground (https://developer.here.com/api-explorer/rest/public_transit/isochrone-search) with the default/demo keys (already in place), then we get a 200 OK response. If we insert our own keys, the request appears to time out/not provide a response.
Any ideas on what we may be doing wrong?
Edit: Using a HERE Maps trial (90 day) account to test functionality.
For using Public Transport API, you need some special agreement with data supplier even for evaluation. Use the Contact us link to request additional permission.
https://developer.here.com/contact-us
https://developer.here.com/rest-apis/documentation/transit/topics/coverage-information.html
The Google translate API FAQ at https://developers.google.com/translate/v2/faq#technical states that the maximum number of characters per request is 5000. However, I am unable to send more than 2000 characters without getting HTTP error 414: The requested URL /translate... is too large to process.
I am getting this from my .NET app but have also reproduced the same error from Fiddler.
Below is the URL I am sending (just over 2000 characters). Am I misunderstanding the 5000 character limit?
https://www.googleapis.com/language/translate/v2?key=MYKEY-MYKEY-MYKEY-MYKEY-MYKEY-MYKEY-KEY&source=en&target=es&q=From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0AIf%20traveling%20to%20the%20west%20From%20Sparta%3A%0D%0A
You'll need to POST the data if you wish to process more than 2000 characters:
All other query parameters are optional. The URL for the GET,
including parameters, must be less than 2K characters.
Note: You can also use POST to invoke the API if you want to send more
data in a single request
https://developers.google.com/translate/v2/using_rest
I use the SoundCloud API to retrieve the stream URL for a streamable track.
I follow the redirect and I end up with an URL that looks like:
http://ec-media.soundcloud.com/eodihgiuh.128.mp3?<a string>
AWSAccessKeyId=<access key>
&Expires=<timestamp>
&Signature=<signature>
or
http://ak-media.soundcloud.com/euieuieie.128.mp3?
AWSAccessKeyId=<access key>
&Expires=<timestamp>
&Signature=<signature>
&__gda__=<a string>
Then I start streaming the MP3 data at this URL.
First I send a HEAD request to read the Content-Length header, so that I know how many GET requests I will have to send in order to play the whole song.
Then I send several partial GET requests, each one with a different Range header.
The problem is that sometimes the HEAD request returns a 403 status code, even though a GET request to the exact same URL returns with a 200 status code. It seems that this happens if and only if the host is ak-media.soundcloud.com.
Is this supposed to happen? I expected the HEAD request to return exactly the same headers as the GET request, only without the body response.
Cheers,
PB
P.S: I should probably mention that my code is not running on a computer, but on an audio device with a tiny 8-bit processor which has extremely limited resources.
Unfortunately, currently we only offer guaranteed proper response for GET requests.
As a hack, you could try to do requests with very short ranges.