Difference between revisions of "GroupServer API"
|Line 65:||Line 65:|
content based on the of the user .
Revision as of 10:06, 14 March 2013
GroupServer does not have an API. That should be changed.
There is a 5 year old ticket on this.
Ideally, a RESTFUL API would exist that lets developers pull the following.
A group object should be accessible by a group id and should include:
- The group's name
- The group's url
- The group's policy
- A reference to a list of the group's members
- A reference to the group's administrators, moderators, and coach
- A reference to a list of the group's topics
- A reference to a list of the group's posts
A list of references to publicly visible groups should also be available.
A topic object should be accessible by one of its post's ids and should include:
- A url to the topic's page
- The subject of the topic
- A reference to a list of posts in the topic
- A list of the keywords of the topic
- A reference to the group that the topic is in
A list of references to publicly visible topics should also be available. There should be the option to specify a group-id to as to retrieve a list of topics of a specific group.
A note about topic/post ids. To my knowledge, there is no canonical id for a given topic. Instead, a topic can be accessed via the id of any post that is found in that topic.
A post object should be accessible by its ID and should include:
- A url to the post's page
- A reference to the topic that the post is a part of
- A reference to the author of the post
- The datetime of the post
- The body of the post
- A list of the keywords of the post
- A list of references to files attached to the post.
A list of references to publicly visible posts should also be available. There should be the option to specify a group-id to as to retrieve a list of posts of a specific group. There should also be the option to retrieve a list of posts for the topic that the post is a part of.
A user object should be accessible by the user's id and nickname, and should include:
- A url to the user's profile page
- The first, last, and full name of the user
- A url to the user's avatar
- A list of references to groups that the user is a member of
- A list of references to posts that the user has made
Any of the list retrieval methods should limit the number of results returned, and allow requests to be made for a specific number of results, specific indices, and offsets. Where it makes sense, a request should also be able to specify an order by parameter.
All of the above GET methods are ok for anonymous users. Like any good API, the GroupServer API should have some means of authenticating requests so that more sensitive information can be made available via the API to clients that have the appropriate permission, or to control the number of requests to the API if needed.
Zope already provides a strong system for allowing/disallowing access to content based on the role of the user. The primary challenge then is to allow a client to authenticate with GroupServer/Zope via the API securely. Beyond that, the challenge is how strictly one want's to adhere to REST (assuming the API is RESTFUL). If we are ok with relying on a cookie to store the authentication token, then nothing else really has to be done. If we are not ok with that, then we must allow a token parameter for API requests that the API view can feed to Zope's understanding of the user state.
- New topics
- New posts
- Changes to user profiles