Talk:GMOD REST Hackathon

Jump to: navigation, search

Programming language groups


  • Jim

Additional documentation/discussion at GMOD_RPC_API/PHP


  • Rob
  • Josh --Coordinator
  • Jay
  • Chris


  • Brian
  • Richard --Coordinator
  • Josh

API structure

  • Controller to handle dispatching requests
  • Plugin layer for data models
  • View layer for rending XML, JSON, etc...

Misc Info

  • POST for read operations is ok to get around URL character limits w/ GET
  • Pretty URLs are limited and we should use a mix pretty URLS and param/value CGI calls
  • Extend services for SO terms (exon, UTRs, etc...)
    • example gene/exon or chromosome/exon

Pretty URLs

  • Do we need mod_rewrite?
    • for php, use directory/index.php? No. appended directory/foo gives a 404

Other Backend APIs to Compare/Be Inspired By

Info from Adrian

From: art@xxxx To: jogoodma@xxxxx Cc: art@xxxxxxx Subject: GMOD REST API feedback


Firstly is there anyone there who I can skype for the first part of the meeting, to follow the discussion?

Secondly, I implemented most of the spec for the Oxford meeting. We have a bit of work to update to our latest libraries which I might do tonight. I have a few observations. I've already mentioned some of these to Giles so sorry if they've already been raised. I love the idea of the common API so in that spirit a few constructive criticisms:

  • I don't think the API is very RESTful, in the strictest sense. See eg

I think the versioned API is a good idea, more important than strict REST compliance. I just wonder if the label *might* cause problems in a future publication or more importantly its takeup amongst purists. But REST is such a overused term that maybe this doesn't matter.

  • A small general problem for us is the use of NCBI taxonomy ids. Our

difficulty is always getting NCBI ids for new projects in a timely matter, and for representing multiple samples of the same strain. It might be good to say that the ids should be NCBI taxonomy ids if possible, but that sequencing centres may also use 'internal' IDs. Effectively this means people should always fetch the .../organisms first to get the ids. This is really just requesting a textual relaxation in the spec. (I'll also repeat my comment from the Oxford workshop that it seems slightly odd that the 2 GMOD URL-related specs use different methods of identifying organisms)

  • Biggest point - the URLs are all constructed to avoid using query

parameters. From the Sam Ruby O'Reilly REST book it certainly doesn't seem to be taboo to use them. One point is that forcing everything into (possibly optional) positions in the URL makes both implementation, and requesting more difficult if you're using a URI template-style implementation, as we are. If you allow query parameters the gene location could be:<api version>/location/chromosome/<name>/gene[.xml | .json]?[min=[fmin/<int>]&[fmax/<int>]&[strand/(1 | -1)]



This looks more natural to me, is more self-descriptive and is completely compatible with REST principles. The implementation point obviously isn't that important as it's a one-off cost but the I think the naturalness is. What do other people think?

  • The final issue I see here is that the Organism XML page is a bit

indefinite. The example links either don't work or return quite different XML. Is it in scope to produce a RNC or XML schema to tie this down?