I get a 403 Forbidden response along with the "serviceErrorCode":100,"message":"Unpermitted fields present in PARAMETER: Data Processing Exception while processing f (truncated...) error when running this get request:
https://api.linkedin.com/v2/adAnalyticsV2?q=analytics&pivot=ACCOUNT&timeGranularity=DAILY&dateRange.start.day=22&dateRange.start.month=09&dateRange.start.year=2020&dateRange.end.day=22&dateRange.end.month=10&dateRange.end.year=2020&accounts%5B0%5D=urn%3Ali%3AsponsoredAccount%3A248XXXXXXXXX&fields=costInUsd,externalWebsiteConversions,impressions,clicks,conversionValueInLocalCurrency&start=0&count=500
I verified that i have the rw_ads and r_ads_reporting permissions.
Anybody know what this could be?
I figured it out. The dateRange is wrong. It needs to be:
dateRange=(start:(day:1,month:9,year:2020))
As Linkedin's API documentation is shit in regards to this it took me a lot of trial and error. I found a partial answer on this stackoverlow post. The final structure is correct but the example isn't. Linkedin's docs say the key is dateRange.start which is wrong.
Related
I'm trying to get a history report for a repository connection over ManifoldCF REST API. According to the documentation:
https://manifoldcf.apache.org/release/release-2.11/en_US/programmatic-operation.html#History+query+parameters
It should be possible with the following URL (connection name: myConnection):
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection
I have also tried to use some of the history query parameters:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?report=simple
But I am not sure if I am using them correctly or how they should be attached to the URL, because it is not mentioned in the documentation.
The problem is also that I don't receive any error, but an empty object, so it is difficult to debug. The API returns an empty object even for a non-existing connection.
However it works for resources, which doesn't have any attributes, e.g.:
http://localhost:8345/mcf-api-service/json/repositoryconnectionjobs/myConnection
or
http://localhost:8345/mcf-api-service/json/repositoryconnections/myConnection
Thanks in advace for any help.
I also wrote a message to ManifoldCF team and they gave me an answer. So I summed up it for you below.
Query parameters go after the fixed "path" part of the URL and are of the form ?parameter=value¶meter2=value2...
So in the same way as in any other URL.
The problem was that I didn't supply the activity(s) that I wanted to match. Possible activities are e.g. fetch, process. My example:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?activity=process&activity=fetch
Finally, the reason why I didn't get an error when I used a connection name that is bogus is because the underlying implementation is merely doing a dumb query and not checking for the legality/existence of the connection name.
I'm using Firebase API to generate short link:
https://firebasedynamiclinks.googleapis.com/v1/shortLinks?key=XYZ
It work most of time and generated expected result like https:// abc123.app.goo.gl/WXYZ but randomly it sometime generated https:// goo.gl/xyz sort of link. And finally when this executed by client it does not contain expected parsed result.
I have no idea why this is happening. Any one suggestion what's wrong going here.
Until today I could do requests such as the following successfully
https://graph.facebook.com/v2.2/[PAGE_ID]/posts?access_token=[TOKEN]&since=2014-03-17T00:00:00Z&until=2014-03-17T23:59:59Z&limit=250&fields=id,message
Today when I tried to make this request I get the following response:
{
"error":{
"message":"(#100) The 'limit' parameter should not exceed 200",
"type":"OAuthException","code":100
}
}
Which is funny because the graph api mentions that the upper bound of the limit parameter is 250. Am I missing something or is there something wrong with the API?
This bug as been corrected as of January 30th.
Post limit change from documented max of 250 to 200 bug report
#Potaoes I suspect this is an error related to them solving some back-end and latency issues. Discussed here. https://developers.facebook.com/status/issues/320942614776706/
They are currently in the middle of push ( I assume to correct this error). https://developers.facebook.com/status/dashboard/
Finally the error has been reported. https://developers.facebook.com/bugs/1518130385135066/
#Vineesh The OP is correct. It's against all the API documentation that the limit has been 250 since v2.0. There has been no documented change to this.
The Error message exactly shows the Error.
The 'limit' parameter should not exceed 200",
You have given limit=250,
reduce the limit then try again.
I have moved my graph requests to a batch, and noticed that when more than one request parameter is passed, the request fails with error 400.
For example, this works when not batched:
facebook->api('/me/friends?limit=5000&fields=id')
But when the same graph url is moved to a batch request, I get a 400 error.
When I remove one of the parameters (either fields or limit), it works:
/me/friends?fields=id
/me/friends?limit=10
Anyone knows if this is a bug or should be like this for some reason?
Finally found the answer to my problem. It appears that the & char must be escaped with %26 in order for this to work.
So my code sample should be:
facebook->api('/me/friends?limit=5000%26fields=id')
Wish this was documented...
I'm designing a REST service and there's a need for a check to see if an address is correctly entered. What I'm thinking about is how you would design a REST interface for checking if an full street address is valid.
I have this /address service and I could for example do a POST /address/validation which returns a xml/json true or false, but it seems quite un-REST-ful to me.
Another way would be to do a GET /address?street=xxx&nr=xxx&zipcode=xxx (and a few more parameters) and return a 200 OK if correct or a 404 Not found if not correct, which may be more REST-ful?
I started doing option 1) but the more I'm thinking about it, option 2) with the GET feels better...
Ideas?
From a RESTful perspective, you're really returning a new resource, call it AddressValidation, that will contain your true or false value. So one approach would be to do a POST to /addressvalidation?street=xxx etc. I'd be fine with returning the result as JSON or using status codes. I'm not sure 404 is appropriate though; you might want to look at this discussion of validation return status codes.
I have the same issue with the GET /address?street=xxx&nr=xxx&zipcode=xxx approach as you propose it. To me, if it returns 404, that means that the address is literally not found (i.e. doesn't exist in the database), rather than that it's invalid (e.g. the zipcode is an invalid format; there can't be any such address). Again, see the linked discussion; it seems like 400 is a more appropriate response.
How about?
GET /addressValidity?street=xxx&nr=xxx&zipcode=xxx
=>
200 OK
Content-Type: text/plain
true
I feel doing POST and returning status codes (200 OK if correct or a 404 Not found if not correct) is more restful. Because you are not GETting something GET doesn't look appropriate. You are POSTing some information to server and it does some processing (validation) and returns some response.