I have a problem with the Soundcloud API when querying an authenticated user's tracks. I'm currently testing on iOS using NXOAuth2 to provide OAuth2 authentication. I am not using the now-deprecated Soundcloud iOS SDK.
If I make a GET request to https://api.soundcloud.com/me/tracks.json?limit=50&linked_partitioning=1, the returned JSON contains 50 tracks, and the string "https://api.soundcloud.com/me/tracks.json?limit=50&linked_partitioning=1&offset=50" for key "next_href". Making a GET request to this URL returns the next page of tracks. This works as expected.
If I make a GET request to https://api.soundcloud.com/me/favorites.json?limit=50&linked_partitioning=1, the returned JSON contains 50 tracks, and the string "https://api.soundcloud.com/me/favorites.json?before=1395763236&linked_partitioning=1&page_number=1&page_size=50" for key "next_href". Making a GET request to this URL returns a JSON with the same set of tracks as obtained with the original URL, and the same "next_href" string.
It looks like /me/tracks.json has not been updated with the new pagination style (still using offsets). However /me/favourites.json has, but does not work correctly for me. Can anyone else clarify similar behaviour? I am hoping there is something I have missed.
Many thanks in advance.
Related
I am trying to find a way to get statistic for the URL from Pinterest API.
Like facebook graph API: URL Object
Or linked in countserv endpoint:
https://www.linkedin.com/countserv/count/share?format=json&url=https://www.linkedin.com/pulse/breaking-5-major-boolean-syntax-changes-irina-shamaeva
I know it is possible because this site is returning the number of pins for given url:
https://www.sharedcount.com/#url=https%3A%2F%2Fwww.facebook.com%2F
Does anyone know how to get these data from Pinterest API?
There is no officially supported way to do this with the developer API. That said, the widgets use this for the count bubbles using this API
https://widgets.pinterest.com/v1/urls/count.json?url=<url>.
I wouldn't depend on it for anything important tho since it is unsupported and can change/be removed at any time.
You can get the number of pins calling this url
http://api.pinterest.com/v1/urls/count.json?callback=&url=http://stylehatch.co
It will return an object like this:
({"count": 0, "url": "http://stylehatch.co"})
Twitter has private endpoints like this one:
http://urls.api.twitter.com/1/urls/count.json
Tweet counts can be fetched from here, but this is not recommended by Twitter. Besides, they keep saying they gonna shut down these endpoints in the near future.
The Site Streams API is now in closed beta, they don't accept applications.
https://dev.twitter.com/streaming/sitestreams
So that leaves is with only one option, the REST API, but I don't see any endpoint there which could return the number of tweets for a given URL.
What's the best way to get this data? Is there an "official" endpoint for this?
Or the only way is to use something like the Public stream API or the REST API search endpoints and filter the results?
The private endpoint will be shut down by 20 Nov and there'll be nothing to replace it. This blog post from Twitter explains the background: apparently it's to do with their move to their new "real-time, multi-tenant distributed database" system codenamed Manhattan.
The REST API will be of limited use for this purpose. You'd have to do a search for your URL, collect each page of results and add up the total number of tweets yourself. For example this request
https://api.twitter.com/1.1/search/tweets.json?q=metro.co.uk&count=100
will get tweets associated with http://metro.co.uk. (It won't work if you just paste this into your browser - you have to authenticate first. You can try this on the Twitter API console tool.) But the Search API returns a max of 100 tweets per page of results, and it only returns tweets from the last 7 days.
It seems the only solution (explained here) is an elaborate one using a Twitter Streaming API. Basically you'd have to create your own app to count relevant tweets. It would open a connection to stream.twitter.com passing your URL as a track parameter. Twitter will return a tweet every time anyone tweets the address, and your app will have to count them. The example given in that post is:
curl -u user:password "https://stream.twitter.com/1/statuses/filter.json" -d "track=https%3A%2F%2Fdev.twitter.com%2Fdiscussions%2F5653"
I'm not sure how you would deal with shortened URLs in this scenario.
This change has meant that third-party services like SharedCount that report a count of Twitter shares are having to stop offering that data. Sorry to give you bad news - I'm really disappointed with this situation myself. It seems crazy that we can't just get a total of tweets for a given URL.
You can find a little bit more about this in this thread.
This is very strange. The request to /tags/chiara8anos/media/recent is working fine.
The problem is that the profile is public (http://instagram.com/chiaratroccoli) and i can fetch all images except this http://instagram.com/p/fYtRx0Qvit/.
The API is not returning this specific post but the hashtag, #chiara8anos, is correctly there as you can see. So the request /tags/chiara8anos/media/recent should have this.
I noticed that the image is not on amazon bucket as is use to be. This specific image is here: http://distilleryimage9.ak.instagram.com/4852dfbc339711e3817122000ab5bea8_8.jpg
If you try to use api-console (http://instagram.com/developer/api-console/) with this request https://api.instagram.com/v1/tags/chiara8anos/media/recent you won't be able to fetch this post even paginating.
Is it a bug? Some limitation from Instagram?
If you check the /users endpoint, that image is returned correctly and has standard_resolution: http://distilleryimage9.s3.amazonaws.com/4852dfbc339711e3817122000ab5bea8_8.jpg
which is the usual AmazonAWS URL This is the endpoint: https://api.instagram.com/v1/users/605729285/media/recent?access_token=
But you are right saying that the image is not returned using the /tags endpoint. It looks like an Instagram bug to me.
I am playing around with Github's API and I noticed that they allow anyone to request all users that have signed up in chronological order.
https://api.github.com/users
http://developer.github.com/v3/users/
I was trying to get the second page but for some reason their pagination isn't working for me. I wasn't sure what I was doing wrong.
https://api.github.com/users?page=2
https://api.github.com/users?start_page=2
http://developer.github.com/v3/ Under "Pagination".
Anyone know the right way to do this?
Check out the returned HTTP headers for the https://api.github.com/users resource. Specifically, look for the Link header, which will look like this:
Link:<https://api.github.com/users?since=135>; rel="next", <https://api.github.com/users{?since}>; rel="first"
So, what you need to do is do an HTTP GET on https://api.github.com/users?since=135 to get the next page. After that, check the Link header again and you will get to the next page, etc. Also notice the provided URI template https://api.github.com/users{?since} which enables you to start at any id.
Using the Contact API v3 I had a working implementation for uploading a photo to an existing contact.
Since a couple of weeks this fails with 404. The implementation has not been changed when the API servers started to sent back 404s and I don't see any indication what exactly changed and would result now in the 404s.
I'm using HTTP PUT + the photo URL of the contact.
One interesting observation I made was that the contact's self-URL changes which each request (the provided details are still always the same and correct).
Did anyone notice something similar ?
Edit: Link to issue: http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3301&q=contact&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Opened%20Summary
tried different photo formats and sizes, different content types and even photos which had been uploaded previously (when it was still working). Nothing changed the behaviour of returning 404.
w.r.t to change contact ids: the contact ID changes between API invocations. I first thought it could be related to reopened connection( no keep-alive) that contact ids change. However what speaks against this being the cause of the issue is that first retrieving a contact and then editing a contact's address is possible without any issues.
authentication does not seem to be problem as well - otherwise editing a contact's address would not work as well.
PS: I'm using the JSON output format when retrieving the contact.
PS2: s/GET/PUT in step 3 ( I tried to change PUT to GET to see if it still returns 404... which it does).
PS3: am not using any client library but implement the protocol directly (which should not be relevant for the HTTP PUT on the photo link
After hours of investigation I found out that this is particular an issue using OAuth1. Using OAuth2 the exact same photo links which had been returned when requesting a specific contact record using OAuth1 work and return the photo data on HTTP GET. I expect HTTP PUT for photo links using OAuth2 to succeed as well.
Remains open if if there's some kind of workaround for OAuth1.