Difference between revisions of "Design Specs: API"

From WormBaseWiki
Jump to navigationJump to search
Line 59: Line 59:
 
|-
 
|-
 
| Create "query language"  
 
| Create "query language"  
| need to create std. data return structures
+
| need to create std. data return structures; need standard syntax
 
| provides mechanisms to do complex queries involving data from related objects; with an accompanying data structure standard, easy access to returned data for view
 
| provides mechanisms to do complex queries involving data from related objects; with an accompanying data structure standard, easy access to returned data for view
 
| complexity, question of robustness
 
| complexity, question of robustness

Revision as of 16:00, 10 February 2010

API Specs

  • Objects stop here -- what is passed to displays will be strings and numbers
  • Define data building blocks for common display formats -- lists, tables, build off these blocks
  • Provide consistent data access methods to above for display
  • Define common data packs? -- e.g. id and common names?
  • Analyze user reported data issues and build more robustness for common problems (e.g. object not found can't call method)

Notes 2010.02.04

  • The API need not be aware of presentation details. It doesn't need to know about tables, for example, although it should handle generic one and two dimensional arrays.
  • We may want to consider passing some objects through to templates. If we pass WormBase::API objects, templates can then do additional on-the-fly data extraction.
  • We probably DON'T want to pass Ace objects. This means that your data munging subroutines will need to do something like:
 $allele = $gene->Allele;
 $returned_data => { data => "$allele" };

This will stringify the name of the object and prevent it from being passed as an object.


Resources

You can find the API in the WormBase mercurial repository:

lib/WormBase/API


There are tests in t/

cd WormBase // the directory where you've checked out your code
prove -l t/API/Object/Gene.t

These are obviously dependent on being able to connect to the database...


Issues Table

Issue Notes Pros Cons
Let ACE objects through
minimal API programming breaking the MVC barriers
Allow API objects trough Need to create std. data passing structures; need to create methods which can use data structures maintain MVC barriers, flexibility for views; need programming from the view side more complex than letting ACE objects through
Create "query language" need to create std. data return structures; need standard syntax provides mechanisms to do complex queries involving data from related objects; with an accompanying data structure standard, easy access to returned data for view complexity, question of robustness
Code to deal with missing objects from tags Analyze user reported errors for priorities provide good measure of robustness added complexity to coding; use 80/20 rule