Add getCurrentUserPerson

[justincy]

I could use getCurrentUserPersonId then pass the ID into getPerson but it would be inefficient because getCurrentUserPersonId fetches the entire person object anyways.

[DallanQ]

I could add this, but the person object would still need to be re-fetched. Here's what's going on under the hood:

• I make a request to get the current user person id, passing an Accept header of application/x-gedcomx-v1+json as well as appending .json to the URL (you'll see why both are necessary below).
• FamilySearch responds with the current user person id, but the response is a 30x status (can't remember which one), that causes the browser to automatically make a new request to the URL in the Location header.
• The new request does not include the Accept header (at least it doesn't in Chrome, I don't know about Firefox or IE; the official spec doesn't say whether Accept headers should be included in redirect requests or not, so browsers are free to choose either way), but because I appended .json to the original request, the URL in the Location header also includes the .json suffix, so the response comes back as unversioned json.
• Since the response is unversioned, and I figure that in the future we'll have application/x-gedcomx-v2+json as well as application/x-gedcomx-v1+json and I'll need a way to distinguish fetching v1 from v2, the only thing I return from the response is the id (under the assumption that the id field will probably stay the same between versions). This allows the user to pass the id into a follow-on getPerson call to get a person with the proper version. I could add a getCurrentUserPerson function, but it would have to do the same thing: get the id from getCurrentUserPersonId and make a follow-on getPerson call to get a person with the proper version.

I kind of wish that FamilySearch wouldn't return 30x response codes that cause the browser to automatically redirect, but I haven't brought this up with them. Maybe I should?

[justincy]

Interesting. You could try bringing it up with FamilySearch, but it would have to be done in a way that doesn't break other clients. A 3xx is the proper response in these scenarios.

Perhaps we could ask for a special parameter or header that changes the response code to a 2xx status.

[justincy]

They've done something similar before. They used to have an exception for RootsMagic where the HTTP status code for throttling matched the code from the old API.

[DallanQ]

I'll bring it up

[stoicflame]

If you want two explicit reads instead of the automatic redirect, then why not a read to the current user and then use the personId to read the person?

There really should be a hypermedia link from the user to the person so you don't have to construct the URI to the person. Tracking that here.

[justincy]

Great idea. I forgot about that.

[DallanQ]

I didn't realize that the current user response already contained the personId. BTW, personId is not one of the fields mentioned in the example response:

https://familysearch.org/developers/docs/api/tree/Read_Current_User_usecase

How about if we drop the getCurrentUserPersonId wrapper, since personId is already available as an attribute from the current user response? Any objections to this?

I will add personId, givenName, familyName, gender, preferredLanguage, and displayName (none of these are in the example response) and remove fullName (which is part of the example response) to the SDK docs here:

http://rootsdev.org/familysearch-javascript-sdk/#/api/user.types:constructor.User

[justincy]

+1

On Fri, May 2, 2014 at 12:47 PM, Dallan Quass notifications@github.comwrote:

I didn't realize that the current user response already contained the personId. BTW, personId is not one of the fields mentioned in the example response:

https://familysearch.org/developers/docs/api/tree/Read_Current_User_usecase

How about if we drop the getCurrentUserPersonId wrapper, since personId is already available as an attribute from the current user response? Any objections to this?

I will add personId, givenName, familyName, gender, preferredLanguage, and displayName (none of these are in the example response) and remove fullName (which is part of the example response) to the SDK docs here:

http://rootsdev.org/familysearch-javascript-sdk/#/api/user.types:constructor.User

— Reply to this email directly or view it on GitHubhttps://github.com/rootsdev/familysearch-javascript-sdk/issues/51#issuecomment-42064755 .

[DallanQ]

done

[justincy]

We have the same 3xx redirect issue with Preferred relationships. Getting the preferred relationship returns a 303.