Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts from building the SDK to inform future development #251

Open
lightclient opened this issue Dec 10, 2018 · 1 comment
Open

Thoughts from building the SDK to inform future development #251

lightclient opened this issue Dec 10, 2018 · 1 comment

Comments

@lightclient
Copy link
Contributor

lightclient commented Dec 10, 2018

I want to leave some thoughts I've had while building the SDK that may help to inform the development of the next iteration of the API.

  • Does it make sense to prescribe one notification to be push and another to be activity? As an open protocol I'd argue that they are all notification and it should be up to developers building on our platform to make that distinction in their frontend by choosing which are quickly visible and through a setting panel that allows users to turn on and off emails for specific notifications.

  • The leaderboard endpoint is a departure from the pattern put in place by bounties, fulfillments, etc where a single entity can be retrieved by drilling down /{entity}/{id} or a list could be retrieved via some query to the /{entity} endpoint. I believe that leaderboard should be generalized and accessible via the /user endpoint and customizable using queries.

  • For continuity sake, I think the categories, skills, tokens, and languages should also follow the /{entity}/{id} || /{entity} pattern.

  • The comments endpoint should be decoupled from a bounty like fulfillments. It may be useful to retrieve all of a specific user's comments.

  • How are we going to seamlessly integrate STB2 where bounties are identified by addresses instead of ids? It doesn't make sense to me to require users who want to know about a bounty at 0x123...456 to first ping our API to determine that bounties id before calling the /bounty endpoint.

I'll add more to this thread as they come up!

@lightclient
Copy link
Contributor Author

After talking with @villanuevawill, we think it makes sense to keep the current comments endpoints and just add a general read-only endpoint to query a user's comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant