E-Democracy Pages Wiki

Search Wiki

 

Tools

 

Difference between revisions of "GroupServer API"

From E-Democracy.org

(PUT)
Line 1: Line 1:
GroupServer does not have an API. That should be changed.  
+
There is a lot of content available on E-Democracy, and a lot of potential uses of E-Democracy as a communications platform across devices and platforms. However, E-Democracy's underlying platform - GroupServer - does not provide an API for accessing or interacting with groups, topics, and posts.
  
There is a [https://redmine.iopen.net/issues/262 5 year old ticket] on this.
+
=Required or Useful Skills=
  
=GET=
+
* '''Python''' - GroupServer is written in Python 2.7
 +
* '''Object Orientation''' - Like most web applications, OO is used significantly in GroupServer.
 +
* '''Model-View-Controller''' - Likewise, the MVC paradigm is used significantly in GroupServer.
 +
* '''Buildout''' - A Python code distribution and development system used by GroupServer. See [[Managing Development in GroupServer and E-Democracy#Buildout]].
 +
* '''Git or Mercurial''' - Both distributed version control systems are used in during development. Fortunately, they are very similar. [[Managing Development in GroupServer and E-Democracy#Code_Repositories]].
 +
* '''Zope''' - The framework that GroupServer is built on. Familiarity with any flavor of Zope or its derivatives (i.e. Plone, Grok) will be very helpful. Even more important is familiarity with the [[Zope Component Architecture]].
 +
* '''API Creation''' - Since this project is about creating an API, experience in designing and developing APIs will be very helpful.
  
Ideally, a RESTFUL API would exist that lets developers pull the following.
+
=Project Plan=
  
==Groups==
+
To develop a project plan for an API, we are working to answer several questions:
 +
 
 +
* What data and functionality should be exposed?
 +
* What type of API should be developed (RESTful vs. RPC vs. something else...)?
 +
* Should the API conform to some existing standard (i.e. [http://opensocial.org/ OpenSocial])?
 +
* What format should the API return data in?
 +
* What will the URL(s) be for accessing the API?
 +
* Should the API be available to all, or require a token to access?
 +
* How should authentication and authorization work?
 +
* How should the API code be organized in GroupServer's codebase?
 +
 
 +
None of these questions have been definitively answered yet. But, significant steps have been taken to answer those questions on this page, on this [https://redmine.iopen.net/issues/262 5 year old ticket] (which will be extended as the project's plan solidifies), and on [http://groupserver.org/groups/development/messages/topic/1JYpRDYVRKTGQOFtOgjHAG/ this thread] in GroupServer's Development group.
 +
 
 +
==Proposed Order==
 +
 
 +
The first phase of the project should involve providing access to content that does not require authentication. The next phase of the project should allow for a client to authenticate via the API. The third phase of the project should allow for adding content based on the authorization of an authenticated client.
 +
 
 +
=What data and functionality should be exposed?=
 +
 
 +
This can be divided roughly into:
 +
 
 +
* What data should a client be able to retrieve (GET)?
 +
* What data should a client be able to write  (POST/PUT)?
 +
 
 +
==GET==
 +
 
 +
Ideally, the API would allow developers pull the following.
 +
 
 +
===Groups===
  
 
A group object should be accessible by a group id and should include:
 
A group object should be accessible by a group id and should include:
Line 21: Line 55:
 
A '''list''' of references to publicly visible groups should also be available.
 
A '''list''' of references to publicly visible groups should also be available.
  
==Topics==
+
===Topics===
  
 
A topic object should be accessible by one of its post's ids and should include:
 
A topic object should be accessible by one of its post's ids and should include:
Line 35: Line 69:
 
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 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.
  
==Posts==
+
===Posts===
  
 
A post object should be accessible by its ID and should include:
 
A post object should be accessible by its ID and should include:
Line 49: Line 83:
 
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 '''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.
  
==Users==
+
===Users===
  
 
A user object should be accessible by the user's id and nickname, and should include:
 
A user object should be accessible by the user's id and nickname, and should include:
Line 59: Line 93:
 
* A list of references to '''posts''' that the user has made
 
* A list of references to '''posts''' that the user has made
  
==Pagination==
+
===Pagination===
  
 
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.
 
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.
  
=Authenticate=
 
  
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.
+
==PUT==
 
+
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 [http://blog.mikepearce.net/2010/08/24/cookies-and-the-restful-api/ 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.
+
 
+
Once authentication is implemented, we should go back trough the list of GET methods and determine which ones can provide more information based on the authentication of the client.
+
 
+
=PUT=
+
  
 
Assuming we can authenticate a client, we should be able to provide the ability for a client to add content to the site. Upon completion of content addition, the client should receive a simple object indicating the status of the addition (Success, Error, etc...) and either a reference to the successfully added content or an explanation of why the content was not added.
 
Assuming we can authenticate a client, we should be able to provide the ability for a client to add content to the site. Upon completion of content addition, the client should receive a simple object indicating the status of the addition (Success, Error, etc...) and either a reference to the successfully added content or an explanation of why the content was not added.
  
==Post==
+
===Post===
  
 
To add a new post, a client will need to specify:
 
To add a new post, a client will need to specify:
Line 87: Line 114:
 
* A list of '''files''' to attach to the post
 
* A list of '''files''' to attach to the post
  
==Topic==
+
===Topic===
  
 
To add a new topic, a client will need to specify:
 
To add a new topic, a client will need to specify:
Line 99: Line 126:
  
 
* A list of '''files''' to attach to the first post of the topic
 
* A list of '''files''' to attach to the first post of the topic
 +
 +
=How should authentication and authorization work?=
 +
 +
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 and functionality can be made available via the API to clients that have the appropriate permission.
 +
 +
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 [http://blog.mikepearce.net/2010/08/24/cookies-and-the-restful-api/ 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.
 +
 +
Once authentication is implemented, we should go back trough the list of GET methods and determine which ones can provide more information based on the authentication of the client.
  
 
[[Category:Technology:Project Ideas]][[Category:Technology:Project Ideas:GroupServer]][[Category:Technology:Project Ideas:Python]]
 
[[Category:Technology:Project Ideas]][[Category:Technology:Project Ideas:GroupServer]][[Category:Technology:Project Ideas:Python]]

Revision as of 14:19, 3 July 2013

There is a lot of content available on E-Democracy, and a lot of potential uses of E-Democracy as a communications platform across devices and platforms. However, E-Democracy's underlying platform - GroupServer - does not provide an API for accessing or interacting with groups, topics, and posts.

Required or Useful Skills

  • Python - GroupServer is written in Python 2.7
  • Object Orientation - Like most web applications, OO is used significantly in GroupServer.
  • Model-View-Controller - Likewise, the MVC paradigm is used significantly in GroupServer.
  • Buildout - A Python code distribution and development system used by GroupServer. See Managing Development in GroupServer and E-Democracy#Buildout.
  • Git or Mercurial - Both distributed version control systems are used in during development. Fortunately, they are very similar. Managing Development in GroupServer and E-Democracy#Code_Repositories.
  • Zope - The framework that GroupServer is built on. Familiarity with any flavor of Zope or its derivatives (i.e. Plone, Grok) will be very helpful. Even more important is familiarity with the Zope Component Architecture.
  • API Creation - Since this project is about creating an API, experience in designing and developing APIs will be very helpful.

Project Plan

To develop a project plan for an API, we are working to answer several questions:

  • What data and functionality should be exposed?
  • What type of API should be developed (RESTful vs. RPC vs. something else...)?
  • Should the API conform to some existing standard (i.e. OpenSocial)?
  • What format should the API return data in?
  • What will the URL(s) be for accessing the API?
  • Should the API be available to all, or require a token to access?
  • How should authentication and authorization work?
  • How should the API code be organized in GroupServer's codebase?

None of these questions have been definitively answered yet. But, significant steps have been taken to answer those questions on this page, on this 5 year old ticket (which will be extended as the project's plan solidifies), and on this thread in GroupServer's Development group.

Proposed Order

The first phase of the project should involve providing access to content that does not require authentication. The next phase of the project should allow for a client to authenticate via the API. The third phase of the project should allow for adding content based on the authorization of an authenticated client.

What data and functionality should be exposed?

This can be divided roughly into:

  • What data should a client be able to retrieve (GET)?
  • What data should a client be able to write (POST/PUT)?

GET

Ideally, the API would allow developers pull the following.

Groups

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.

Topics

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.

Posts

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.

Users

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

Pagination

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.


PUT

Assuming we can authenticate a client, we should be able to provide the ability for a client to add content to the site. Upon completion of content addition, the client should receive a simple object indicating the status of the addition (Success, Error, etc...) and either a reference to the successfully added content or an explanation of why the content was not added.

Post

To add a new post, a client will need to specify:

  • The id of the topic being added to
  • The body of the new post
  • The email address the client wants to use to make the post

Additionally/optionally, a client can also specify:

  • A list of files to attach to the post

Topic

To add a new topic, a client will need to specify:

  • The id of the group the topic is being added to
  • The subject of the topic
  • The body of the first post of the topic
  • The email address the client wants to use to create the topic

Additionally/optionally, a client can also specify:

  • A list of files to attach to the first post of the topic

How should authentication and authorization work?

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 and functionality can be made available via the API to clients that have the appropriate permission.

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.

Once authentication is implemented, we should go back trough the list of GET methods and determine which ones can provide more information based on the authentication of the client.

 

Home - Mobile - Forums - Wiki - Blog - About - Help - Contact - People - Donate - Rules - Archives