This is the resource I calling for:
https://api.twitter.com/1.1/statuses/user_timeline.json&count%3D2%26oauth_consumer_key%3DVnNeRUCEZAEQFgSR6j7RA%26oauth_nonce%3D47ce3f3bc553afa24qwwWsa6d651d697407d279%26oauth_signature_method%3DHAS12MAC-SHA1%26oauth_timestamp%3D13739599ASdas95%26oauth_token%3D1041as30304-HEYQ1S65ybBYP2J1Xey1sK7xql1nyU2ykZDr9txA%26oauth_version%3D1.0%26screen_name%3DMyAgency
but I get an empty page with NetworkError: 400 Bad Request.
Where am I wrong? And where do I check this?
This status code will be returned during version 1.0 rate limiting. In API v1.1, a request without authentication is considered invalid and you will get this response.
If you're using version 1.0 - The Twitter API only allows clients to make a limited number of calls in a given hour. This policy affects the APIs in different ways.
Related
Here is the full question :
As a Portfolio API, I should be able to retrieve details for a given Account and Account type from Balance API, so that i can pass over the same to the UI for the end users to view the same.
Scenario 1 - Verify the response when Portfolio API invokes the
POST /v1/accDetails endpoint for a given account details (Checking)
Given client has a valid auth token for the api
And Portfolio API has the following
Account Number 1234567890 (10 characters).
Account Type 'CHQ' (3 characters)
When Portfolio API sends a POST request to Balance API
Then Portfolio API will receive the response code as <00>
And response body will have the following (not limited to below fields)
Account Type, Account Number, Account ID, Account Name, Account Balance, Product TypABA Number, Interest Rate, Interest Earned to DateStatus.
Now my question is we can do this using GET Method but can we do this using POST method or not? When we use post that mean we are going to add something but I do not want to add any account. I just want to get account details.
Since you have only a few parameters to send via GET, the best approach is to use [GET].
We can use the [POST] if we really need it to do so.
But if you can use [GET] for that, then the best approach is to use [GET].
Also can refer: REST API using POST instead of GET.
I'm using the Xero API to post multiple invoices to Xero.
This works fine if all the invoices are valid. I get a HTTP 200 response with the GUIDs of the newly created invoices.
However, if one of the invoices has an error I get a BadRequest response with a ValidationException.
I would expect the xero system to work transactionally, and if any of the invoices have a validation error, then none of them would be created. However, what I'm observing is that the valid invoices from my request are still created in the system, even when there is an invalid one present in the request.
The problem is that the response from the Xero API just has the details of the validation error. Nowhere in the response do I get the details of the newly created valid invoices. So I have no way of knowing what the GUIDs of those new invoices are.
Has anyone else experienced a problem like this, and how did they overcome it?
I am reluctant to send the invoices individually as their own guidance recommends posting multiple entities at once to avoid exceeding the rate limits of the API.
By default, the Xero API returns a "summarized" view of your errors when one or more resources in a PUT/POST request are invalid.
If you take a look at the Creating many resources section on this page of our docs you'll see an example of how to turn this off using the query parameter ?SummarizeErrors=false.
Cheers,
Matt
We are trying to call one of Google's APIs and analyze the data and then display it for the user on our site. We realize we can make calls to the API through our server using php or python, but because of Google's limit, we are looking for an option that will have the API call come from the user, instead of our server. Is there a way for a web app to distribute the requests amongst the users instead of make all the calls from our server?
Thank you very much as this has been a tricky one to Google.
I highly doubt that this is possible. The API request is per API key and you can't provide every user with their own API key.
If the scenario you are trying to achieve requests possibly the same data for multiple users. I highly suggest you save/cache the API request. This will minimize the times your server send API request to google since you saved that request to your server. You can then set an expiration for your saved/cached API request to renew X days.
Scenario
user 1: request data for item 123 from API.
server: sends request to API server, and save
user 2: request data for item 123
server: return saved API response
We have classified goods website where we do not have login but users can view products listed by other users. To view details of other users, they have to provide their contact details. To verify if user has provided the correct mobile number, we send back OTP code to the number. The API flow looks like:
//API to be hit when user fills form to get seller details of particular stock (this expects "stockId" and "mobile" as input):
POST /api/lead/
{
"stockId": 123,
"mobile": 9890384328
}
Response of API if "mobile" is already verified (Response code: 200):
{
"sellerName": "xyz",
"sellerMobile": "+123232312",
"sellerAddress": "21, park street, new york"
}
Response if "mobile" is NOT already verified (Response code: 403):
{
"OTP verification required. OTP is sent to the mobile number."
}
User sends back request again with OTP received on mobile to the same lead API:
Request Payload:
{
"stockId": 123,
"mobile": 9890384328,
"otp": 1234
}
It sends back seller details in response if OTP is correct. If OTP
provided is not correct, the response is:
{
"Incorrect OTP."
}
I see few issues in this API design:
This API is doing lots of working i.e. returning back seller details, returning back OTP, verifying OTP etc. We can easily break OTP related functionality to some other API. For example one API to generate OTP i.e. GET /api/otp/, other API to verify OTP i.e. POST api/verifyotp/. This would increase number of API calls from client i.e first client will initiate POST lead API, if number is not verified, client will hit OTP API. To verify by OTP it will call verifyOTP api. If it gets verified, it will call leads API to fetch seller details. So, basically it makes 4 API calls vs 2 API calls in above approach.
This is non-complaint with HATEOS which suggests "A REST client enters a REST application through a simple fixed URL. All future actions the client may take are discovered within resource representations returned from the server."
Can someone suggest which approach is better?
Simple answer: no.
It is called single responsibility principle for a reason.
Allowing for more than one responsibility in the your public API means that the API "endpoint" has to understand the different responsibilities to "dispatch" to the "correct" implementation for each of these aspects. Or you allow your dual-responsibility API design to corrupt your implementation by having a single thing providing that implementation.
And beyond that: when you have different responsibilities, the range of OK/error return codes simply turns more complicated. That simply makes "everything" harder. For you to write tests - but also for the clients using your API.
In your case, the user does:
use /api/lead first
to be told about "not verified"
use OTP generation API to get the verification code
to then use a specific OTP API to submit verification code
to then use /api/lead again
Instagram changed the way it rate limits like, comment and relationship endpoints in its API recently...you can sign API POST requests with an HMAC hash of your client secret and app IP address. I am doing this successfully. I know this because I get a 403 error message if I don't include the a properly hashed X-Insta-Forwarded-For header; get a 200 success message if it is included).
Still, I'm being rate-limited to 30 "like" calls per hour (the limit for unsigned requests); 100 is the limit for signed requests. Anyone know why this might be?
Updated docs are here: http://instagram.com/developer/restrict-api-requests/
and
here: http://instagram.com/developer/limits/
Apparently my Instagram client credentials had been flagged by Instagram, and they were limiting me based on past behavior of my app. I registered a new client with Instagram here: http://instagram.com/developer/clients/manage/, re-authenticated with the new app, plugged the new secret into my code to sign my requests, and I was able to like 100 IG posts within an hour. Good to go!
I faced the same problem and I managed to solve it by simply revoking app token from user panel. No need to create new app.