[ensembl-dev] New REST server is out!

Andy Yates ayates at ebi.ac.uk
Thu Jun 26 17:45:15 BST 2014


Hi Michael,

I think it's better to see beta as our first attempt at writing a REST service and this new version is what happens when we try to expand it's scope. Whilst the output of the data has changed dramatically and is not 1:1 with the remainder of the style of the rest service this is backed by a stupendous increase in speed. We will take on your comments though especially as now is the time to make changes. We are also investigating URL versioning to ensure that transitions can be handled gracefully without the need for sudden abrupt changes. Since we are now moving into a solid service these changes will happen with the upmost care & attention and we will continue to learn from services like GitHub about how to design good RESTful interfaces.

I hope that even though you are not happy with the manner of the changes you will be happy with the results

Cheers,

Andy

------------
Andrew Yates - Ensembl Support Coordinator
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton
Cambridge CB10 1SD
Tel: +44-(0)1223-492538
Fax: +44-(0)1223-494468
http://www.ensembl.org/

On 26 Jun 2014, at 17:19, Michael Heuer <heuermh at gmail.com> wrote:

> Will McLaren <wm2 at ebi.ac.uk> wrote:
> 
>> Hi Michael,
>> 
>> Thanks for your feedback.
>> 
>> The new VEP REST endpoints now use the same backend code as the VEP script
>> and web interfaces. This has some big advantages, largely in performance and
>> in the ease with which we can develop and evolve all three methods of VEP
>> access.
> 
> The data returned by these endpoints look nothing like the data
> returned by any of the other endpoints, I see that as a major problem.
> 
> 
>> There are downsides, one of which is the output generated by the VEP
>> endpoints is now a very basic JSON conversion of the data structure returned
>> by the VEP code. This data structure evolved primarily to feed the VEP
>> script, which uses these odd upper/lower cases in its field names - the
>> upper case ones generally are those found in the "Extra" field of the VEP
>> script's output format. You can find a list of the fields and their
>> definitions here:
>> 
>> http://www.ensembl.org/info/docs/tools/vep/vep_formats.html#output
>> 
>> The beta.rest.ensembl.org server is still available if you wish to continue
>> using it for now.
>> 
>> Of course we will take any feedback on board and if we decide to make any
>> changes then the earlier the better in terms of reducing impact on our
>> users.
> 
> Right, that is what beta typically means, things may change.
> Shouldn't these rather significant changes have been made there first
> for feedback?
> 
>   michael
> 
> 
>> On 26 June 2014 16:41, Michael Heuer <heuermh at gmail.com> wrote:
>>> 
>>> Hello Magali,
>>> 
>>> The format of the data returned by the vep endpoints is completely
>>> different now, would have been nice to have some advanced notice.
>>> 
>>> In fact, the conventions used to convert to JSON are completely
>>> different than used elsewhere and are in some cases invalid, e.g.
>>> 
>>> {
>>>  "SYMBOL":"BRAF",
>>>  "SYMBOL_SOURCE":"HGNC"
>>>  "STRAND":-1
>>> ...
>>> 
>>> Why ALLUPPERCASE for the field name?
>>> 
>>>  "Uploaded_variation":"COSM476",
>>> ...
>>> 
>>> Why Sentence_case for the field name?
>>> 
>>>  "Existing_variation":"rs113488022,COSM18443,COSM476,COSM6137",
>>>  "CLIN_SIG":"other,pathogenic,untested"
>>>  "Consequence":"missense_variant,NMD_transcript_variant"
>>> ...
>>> 
>>> Why is an array of string values shoved into a single value?
>>> Shouldn't these be array values?
>>> 
>>>  "Location":"7:140453136"
>>> 
>>> Location used to be a nested object:
>>> 
>>>         "location" : {
>>>            "strand" : 1,
>>>            "name" : "7",
>>>            "coord_system" : "chromosome",
>>>            "start" : 140453136,
>>>            "end" : 140453136
>>>         },
>>> 
>>> 
>>> This looks to me like a step backwards for this particular endpoint.
>>> 
>>>   michael
>>> 
>>> 
>>> On Thu, Jun 26, 2014 at 5:34 AM, mag <mr6 at ebi.ac.uk> wrote:
>>>> Dear all,
>>>> 
>>>> We are pleased to announce the release of our new REST server,
>>>> http://rest.ensembl.org
>>>> 
>>>> This new server comes with a higher rate limit, POST support and a huge
>>>> documentation rewrite.
>>>> 
>>>> POST support is provided for the VEP and archive endpoints.
>>>> We have also added a new variation endpoint to retrieve information
>>>> about a
>>>> variation id, including phenotypes, genotypes and population studies.
>>>> Full details of the new release can be found here:
>>>> https://github.com/Ensembl/ensembl-rest/wiki/Change-log
>>>> 
>>>> The rate limit has been increased, allowing up to 15 requests per
>>>> second.
>>>> 
>>>> The current beta server, beta.rest.ensembl.org, will remain active until
>>>> release 76, scheduled for end of July.
>>>> 
>>>> We encourage you to follow the guidelines on our wiki
>>>> (https://github.com/Ensembl/ensembl-rest/wiki/1.0-To-2.0-Migration) to
>>>> update your scripts to use the new version before beta is retired.
>>>> 
>>>> If you are new to REST, please use our wiki
>>>> (https://github.com/Ensembl/ensembl-rest/wiki) to get started.
>>>> 
>>>> 
>>>> Regards,
>>>> Magali
>>>> 
>>>> _______________________________________________
>>>> Dev mailing list    Dev at ensembl.org
>>>> Posting guidelines and subscribe/unsubscribe info:
>>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>> Ensembl Blog: http://www.ensembl.info/
>>>> 
>>> 
>>> _______________________________________________
>>> Dev mailing list    Dev at ensembl.org
>>> Posting guidelines and subscribe/unsubscribe info:
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog: http://www.ensembl.info/
>> 
>> 
>> 
>> _______________________________________________
>> Dev mailing list    Dev at ensembl.org
>> Posting guidelines and subscribe/unsubscribe info:
>> http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
>> 
> 
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/





More information about the Dev mailing list