[ensembl-dev] REST API differences grch37 vs current

[Kieron Taylor]

Beat Wolf,

Our web team has fixed the issue, and now the grch37.rest.ensembl.org/vep endpoint is in agreement with rest.ensembl.org/vep endpoint. A patch existed but had not been applied to our GRCh37 server. Thank you for reporting this bug!


Regards,

Kieron


> On 2 Jan 2018, at 10:22, Kieron Taylor <ktaylor at ebi.ac.uk> wrote:
> 
>> 
>> On 21 Dec 2017, at 10:56, Wolf Beat <Beat.Wolf at hefr.ch> wrote:
>> 
>> Hello,
> 
> Hi,
> 
>> 
>> i have an issue when trying to write a generic client for both grch37 and the current ensembl REST api.
>> 
>> 
>> In the VEP endpoint you can compare those two requests:
>> 
>> http://rest.ensembl.org/vep/human/id/rs28997576?content-type=application/json
>> 
>> 
>> http://grch37.rest.ensembl.org/vep/human/id/rs28997576?content-type=application/json
>> 
>> 
>> In the current version, the clin_sig and pubmed field is an array, in the grch37 version it is a string that separates the values with comas.
>> 
>> 
>> This is not the first time fields seem to randomly change between arrays and strings, i also never see those changes in the changelog.
> 
> Changes in the VEP (itself a discrete product) are acquired by the REST service, and it is not always obvious that an entry in the changelog is needed. We shall endeavour to improve our reporting of these things.  
> 
> The two services should have the same software, but differing data as appropriate to the human assembly version. As such you should not be seeing the discrepancy.
> 
> 
>> This makes developing a stable client for the ensembl API very hard. The fact that there are no REST archives makes it even harder. At least for the biomart interface i can always use the second last release, to have a stable endpoint and move to the new release when i'm sure i found all undocumented changes.
> 
> We have REST archives to keep in line with our website archive policy as of Ensembl 87. They are accessible via both release number and month of release as follows:
> 
> Ensembl 87: dec2016.rest.ensembl.org/ or e87.rest.ensembl.org
> Ensembl 88: mar2017.rest.ensembl.org/ or e88.rest.ensembl.org
> ...
> 
> The GRCh37 server is already an archive of sorts and we have current plan for providing archived releases of this service. It should have a stable interface except where stated in the REST change log. We do extend the functionality and patch bugs for the GRCh37 service where software allows. Apparently we should mention the archives more explicitly too!
> 
>> I would like to reinterate my wish for a full GRCH37 archive as well, to have a stable endpoint. Currently i'm forced to use the feb2014 archive to be sure nothing breaks due to undocumented changes.
> 
> Thank you for telling us about your needs. We can review our policy in respect of GRCh37 provisioning, but you should plan around not having a GRCh37 REST server archive for every release for the time being.
> 
>> I hope this email wasn't too pessimistic, i simply want to alert you to the issue that without stable archives its very hard for application developers to use the ensembl api.
>> 
>> And i'm pretty sure that difference between grch37 and the current api is not intended.
>> 
>> 
>> Kind regards
>> 
>> 
>> Beat Wolf
> 
> 
> Regards,
> 
> Kieron
> 
> 
> Kieron Taylor PhD.
> Ensembl Developer
> 
> EMBL, European Bioinformatics Institute
> 
> 
> 
> _______________________________________________
> 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/