[ensembl-dev] New REST server is out!

[Kieron Taylor]

Hi Brett,

Reasons to think before you leap:

1) The local VEP script will be faster, because there is overhead in the 
networking and server layers that you don't really need (unless you 
already have something encapsulating the VEP script for multiple users).

2) The effort required to get it up and running, with plenty of 
dependencies, local database copies, VEP fasta caches, indexes, and 
server config. Our ability to support you on unfamiliar architectures is 
limited.

3) The installation guide 
[https://github.com/Ensembl/ensembl-rest/wiki/REST-Installation-and-Development] 
is your best bet, but it has not been thoroughly tested with our current 
release yet. We will improve it if needed.

4) Our REST server is backed by more hardware now than in beta, so you 
might be able to use rest.ensembl.org to do the work anyway. Network 
latency is not necessarily the biggest factor when you're submitting 
1000-strong batches.

Reasons in favour:

1) Turn-around time of smaller queries and batches
2) Coolness
3) Relaxed limits on batch size and frequency
4) Custom behaviour

We're happy to hear of your interest, so please contact us if you have 
any difficulties.


Regards,

Kieron Taylor
Ensembl Core

On 26/06/2014 15:51, Brett Thomas wrote:
> This sounds great!
>
> I'd love to replace the current VEP perl script with a locally deployed
> REST instance - is there any reason you'd discourage this?
>
>
> On Thu, Jun 26, 2014 at 6:34 AM, mag <mr6 at ebi.ac.uk
> <mailto: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
>     <http://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)<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)<https://github.com/Ensembl/ensembl-rest/wiki>
>     to get started.
>
>
>     Regards,
>     Magali
>
>     _______________________________________________
>     Dev mailing list Dev at ensembl.org <mailto:Dev at ensembl.org>
>     Posting guidelines and subscribe/unsubscribe info:
>     http://lists.ensembl.org/mailman/listinfo/dev
>     Ensembl Blog: http://www.ensembl.info/
>
>
>     The information in this e-mail is intended only for the person to
>     whom it is
>     addressed. If you believe this e-mail was sent to you in error and
>     the e-mail
>     contains patient information, please contact the Partners Compliance
>     HelpLine at
>     http://www.partners.org/complianceline . If the e-mail was sent to
>     you in error
>     but does not contain patient information, please contact the sender
>     and properly
>     dispose of the e-mail.
>
>
>
>
> _______________________________________________
> 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/
>