I've been using Google Plus HTTP API for several weeks now and I'm experiencing a strange issue.
When I try to retrieve public activities from this community: https://plus.google.com/communities/115653528125420367824, I always get 4 results, no more. I've tried increasing the maxResult parameter of the request but it doesn't change anything...
And when I use the nextPageToken to retrieve the missing activities, the "items" field of the response is empty.
You can try it yourself with the Google APIs Explorer here: https://developers.google.com/apis-explorer/#p/plus/v1/plus.activities.list?userId=115653528125420367824&collection=public you will see that only 4 activites are returned and the next page of result is empty.
This is really strange and happened recently, it used to work fine. Maybe it is caused by the fact that the content of some activities of this community contains a stringified JSON object. What do you think?
The activities methods are only supported for retrieving posts by users and Google+ Pages. They are not supported for use with Communities and should not be expected to work correctly. There is definitely no guarantee that this behavior while it might have worked or currently works in some cases today will continue to work in the future.
Related
I am currently doing some work with the Canvas LMS REST API and have run into an issue when trying to retrieve a list of all enrollment terms defined in the system. When viewing the terms in the online system, I can see all the terms that have been created, from the first ones up to the furthest defined semester. However, when I try to get a list of terms using
GET /api/v1/accounts/:account_id/terms
I only receive a list of 10 terms, while the rest are missing. Does anyone know what could be causing this?
Additionally, is there a difference between a Term and an EnrollmentTerm object? I only see API calls for EnrollmentTerm objects, while a Term seems to be a subset of the data contained in an EnrollmentTerm that only gets passed within a Course. Could someone explain if there is an important difference here, and what I may be missing?
Lastly, could anyone point me towards some information about error codes that are returned from an API call? For example, when I use
POST /api/v1/accounts/:account_id/terms
with some associated parameters, I get a 400 bad request response. When the parameters are incorrectly named, I get a 500 response instead. Any guidance on this matter would be very helpful.
Let me know if there is anything I can do to help clarify things. Thanks for your help!
I got into contact with Canvas developers and found out that this was caused by how they paginate their API responses. Their default cap appears to be at 10 per response, but this can be extended up to 100 by adding ?per_page=100 at the end of the query like so:
POST /api/v1/accounts/:account_id/terms?per_page=100
Additional pages can be retrieved using the URLs returned in the Link header of the response. More info on that can be found here.
An example Link header would be:
<https://<canvas>/api/v1/accounts/:account_id/terms?page=1&per_page=10>; rel="current",
<https://<canvas>/api/v1/accounts/:account_id/terms?page=2&per_page=10>; rel="next",
<https://<canvas>/api/v1/accounts/:account_id/terms?page=1&per_page=10>; rel="first",
<https://<canvas>/api/v1/accounts/:account_id/terms?page=10&per_page=10>; rel="last"
The URLs in the Link header are only included when they are relevant, so the first page will not return a "prev" link and the last page will not return a "next" link, for example.
I'm trying to get a users profile information for google+ via the .NET API but am having trouble.
Does anyone know if they have changed how the special ID "me" works?
In the documentation it says this can be used as a special ID to get the currently authenticated users information however this throws a 404 from both the API in my code and on Google's own test page https://developers.google.com/+/api/latest/people/get. I was logged in when trying this.
Does anyone know how to get the user ID as I would happily use that instead of me but it isn't returned after the user authenticates as far as I can see (just an authcode)?
I also tried using user IDs returned when using the standard .net Oauth stuff but it isn't the correct ID, I assume it is for something else.
As for my method of getting to this stage, I first downloaded the example files here: http://code.google.com/p/google-api-dotnet-client/wiki/GettingStarted
They don't have a plus example so I took the Tasks.ASP.NET.SimpleOAuth2 example and swapped out tasks (which worked fine) for the plus equivalent.
I also tried rolling this into my own project.
Neither worked. I get the user forwarded to Google where they give me access fine and then when I return they are authenticated successfully as far as I can see, however when I call service.People.Get("me") it returns a 404.
If anyone could help with the above questions (using me, or gettign the user ID) I would appreciate it.
To the moderator who closed the initial version of this question, I have tried to make this as direct a question as possible so please don't close it. This is a legitimate question I would really like help getting to he bottom of.
This is now out of date given recent platform updates. Although the plus.me scope still exists and this code will work, you should be using the plus.login scope for retrieving profile data in C#. For a great way to get started with retrieving and rendering profile information, please start from the Google+ C# quick start available here:
https://developers.google.com/+/quickstart/csharp
First off, the 'me' id still works and is unchanged. The way that it works is:
You authenticate the user using a standard OAUTH2 flow
You use the library to perform a People.get with the special value 'me'
The 404 error code is a little troubling, this means that the client isn't finding the endpoint. To debug this, you might want to use a packet sniffer like fiddler to see what the actual URL it's querying is.
Anyways, how about some C# code. The following example shows how to use the plus service to get the currently authenticated user (assuming you have authenticated someone). What's different from your snippet is that you need to form a get request for the API call, then run fetch on the get request. I've included the following example, for getting 'me', and the following code works:
var auth = CreateAuthenticator();
plusService = new PlusService(auth);
if (plusService != null)
{
PeopleResource.GetRequest prgr = plusService.People.Get("me");
Person me = prgr.Fetch();
}
All of the configuration of the server and getting a client working is pretty hard and pasting all of the code here would be less helpful than just giving you a sample.
And so... I have written a sample application that demonstrates how to do this and also includes a wrapper that makes it easier to develop using the Google+ API in C#. Grab it here:
Google+ C# Server-Side demo and library
Seems you need to use:
Person test = service.People.Get("me").Fetch();
and not
req = service.People.Get("me");
Person test = req.Fetch();
Even though they seem to be identical the first works and the second doesn't.
Still not sure why google's own page doesn't work though. Now to find out how to add things to the scope like birthday.
According to the Trello API documentation, it is possible to return a member's avatarHash as part of the data for the cards on a list. I should be able to use the feed from either of the following:
https://trello.com/1/lists/[LIST_ID]/cards?member_fields=all
https://trello.com/1/lists/[LIST_ID]/cards?member_fields=avatarHash
However, for me anyway, the data is exactly the same with or without the query paramaters. I have also tried adding my application key and a token to the URL, but still no success.
What I actually want to do is get the URI for a member's avatar, and I believe I can build the correct one with the hash. Any help to do this or any pointers as to what I am doing wrong will be greatly appreciated.
Trello's documentation for their API shows that there are optional fields, but it isn't clear or even stated (although fairly obvious after reading) that for the member_fields parameter to be valid, there should also be members=true specified as part of the URI.
I came across this when inspecting the API calls Trello make themselves and having removed everything but member_fields, things even went missing for them, but adding members back in worked as expected.
Right now, my API call is finally working and looks like this:
https://trello.com/1/lists/[LIST_ID]/cards?members=true&member_fields=avatarHash
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.
Graph API is not returning image("picture" attribute) for objects corresponding to community pages, which used to be returned earlier. For example this https://graph.facebook.com/178790412179919 does not have picture attribute whereas the corresponding page has an image.
Also the FQL query done on the "albums" connection for some objects does not have a "cover_pid" attribute for an album corresponding to type "profile", which again used to work earlier.
Does anybody know if anything has changed in Graph API corresponding to this in last couple of weeks (I am fairly confident it used to work earlier in the expected way). I looked through Facebook API release notes but could not find any changes corresponding to this. Please let me know if this not appropriate post for this forum.
https://developers.facebook.com/docs/reference/api/page/
picture is a connection, not an attribute. So ...
https://graph.facebook.com/178790412179919/picture
And as the docs say: Returns a HTTP 302 with the URL of the user's profile picture.
Kinda goofy? Yes, but it works exactly as the docs say it does. I suspect they implemented it this way so it could easily be used in an <IMG> tag.
UPDATE:
It still works via FQL. In your case:
https://api.facebook.com/method/fql.query?query=SELECT+page_id%2C+pic+FROM+page+WHERE+page_id+%3D+178790412179919&format=json
I can confirm that this PREVIOUSLY worked, but NO LONGER works. Facebook have removed the picture connection from Community Pages.
I suspect the reason is that most of these images are pulled from Wikipedia, and there was a licensing / attribution issue.
Unfortunately, Facebook is no longer a reliable source of images for entities (e.g. bands).