Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Should /profiles "id" be "singly"? #260

Closed
kristjan opened this Issue · 12 comments

4 participants

@kristjan

The rest of the services are referenced by their name, but the Singly ID is "id". RESTfully, it gives a good handle for libraries expecting an id field, but conceptually, it's inconsistent.

GET /profiles

{
  "id": "d6fc498925eee5135e61ca2258b4a5a6",
  "twitter": "5746882",
}

Thoughts?

@quartzjer
@kristjan
@quartzjer
@kristjan
@quartzjer

Haha, I shoulda been more clear, that's what I get for replying fast while mobile!

There will be a unified singly id/account, both an implicit one based on the email address and explicit one once they interact w/ singly... but I don't think we ever want to expose that in the api to an app, they get their own id with their own view into whatever is auth'd to them, but no global canonical id, I'm pretty uncomfortable with that at scale.

@smurthas

Asking the app teams to weigh in on the id vs singly vs account terminology.

@joshkehn

The id field was confusion at first when it came back in the all profile call. Calling it singly would be an improvement, but moving it outside of that array would be better.

but no global canonical id, I'm pretty uncomfortable with that at scale

Why? Is id generated per-user per-application? Why can't we have a canonical user id that every user has and gets passed to the app? Unless you're doing the data restrictions based on that id and not based on the app that requests the information.

@kristjan

Coming back in to advocate at least renaming id -> singly for clarity, but I agree with @joshkehn that it should be removed from /profiles. Maybe to /self, since it feels like data similar to /services/*/self.

@smurthas smurthas referenced this issue in Singly/API
Closed

Should /profiles "id" be "singly"? #116

@smurthas

We haven't anyone complain about this or be confused

@smurthas smurthas closed this
@joshkehn

It's confusing from the perspective where you're getting information back about connected profiles and don't expect Singly to be a connected profile. It makes for some interesting exclusion logic like:

services = [ service for service in connected if service != "id" ]
@smurthas

@joshkehn We are working to move everything to the /profile (singular) endpoint, which has much clearer id and services distinction.

@joshkehn

That's great, happy to hear it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.