GET and SMILES interference

When reviewing our old web services documentation (https://www.ebi.ac.uk/chemblws/docs), you will notice some methods can be accessed by both: GET and POST. One thing these methods have in common is that they all accept SMILES as search parameter. Why? Well, it turns out there are some SMILES, that can not be handled via GET, when using old web services. Take this SMILES as an example: [Na+].CO[C@@H](CCC#C\C=C/CCCC(C)CCCCC=C)C(=O)[O-] and you will see, that you can't construct a valid URL using 'https://www.ebi.ac.uk/chemblws/compounds/smiles/' as a base. To 'GET' around this issue, you will need to use POST. This is a bit sad, as it means you can not put a link to such a compound on your blog or ask about it on chemistry forum or send it to your friend via Skype :( What's more, if you would like to use POST for a non-SMILES method (e.g. get all assays by ChEMBL ID), you would also be out of luck.

When reviewing the documentation of the new web services (as we asked you in the previous blog post), you will probably notice, that none of the methods mention POST support. What does it mean? First of all, it means that you can achieve everything using GET. You can easily retrieve data for the SMILES string above using GET, you just have to be careful. Placing a SMILES strings in URLs can be tricky. This is because they often contain characters that are not allowed in URLs and should be encoded, according to the URI standard. Encoded how? The standard mechanism to encode URLs is called percent-encoding and it is widely accepted by modern web browsers and other web tools, such as curl or wget.

In fact, some browsers hide the percent-encoding from users, as we will see soon. So the percent-encoded URL of our molecule looks like this:

https://www.ebi.ac.uk/chembl/api/data/molecule/%5BNa+%5D.CO%5BC@@H%5D%28CCC%23C%5CC=C/CCCC%28C%29CCCCC=C%29C%28=O%29%5BO-%5D

Not very readable... But try to open this link in Firefox and in the address bar you will see this:

https://www.ebi.ac.uk/chembl/api/data/molecule/[Na+].CO[C@@H](CCC%23C\C=C/CCCC(C)CCCCC=C)C(=O)[O-]

Much better, only one sign, #, is encoded! What if you try to open the second link in browser? In Firefox this should work. All other popular browsers will return 404 - not found and curl will complain:

	curl "https://www.ebi.ac.uk/chembl/api/data/molecule/[Na+].CO[C@@H](CCC%23C\C=C/CCCC(C)CCCCC=C)C(=O)[O-]"
	curl: (3) [globbing] error: bad range specification after pos 49

view raw cur.sh hosted with ❤ by GitHub

So what to do?

1. These are characters, that always have to be encoded:

% change to %25, because percent is a special 'escape' character in percent encoding.
# change to %23, because not encoded hash sign is an indicator of the Fragment identifier part of URL, which is only used in browser and is not send to server.
\ change to %5C, because all browsers apart from Firefox are changing not encoded backslash to forward slash as explained here.

2. This is a character, that can not be encoded:

Forward slash / can not be encoded as %2F because our Apache server configuration will return a 404 for URLs containing %2F. The security reasons are described in the Apache documentation. This is particularly annoying, as it means that you can not use online percent-encoders if your SMILES contain forward slashes.

How to make your life with SMILES simpler?

1. Use Firefox - this browser does a great job when it comes to encoding. Although FF is unable to guess in which context you are using % and #, so you will still encode those two characters before pasting it into the address bar, but the rest of special characters will be encoded correctly, so then you can copy the URL from Firefox to other browsers and it will just work.

2. Use cURL - just as with Firefox, you have to encode % and #, but the rest will be handled properly, you just have to use '-g' flag, which switches off the URL globbing parser:

$ curl -i -g "https://www.ebi.ac.uk/chembl/api/data/molecule/[Na+].CO[C@@H](CCC%23C\C=C/CCCC(C)CCCCC=C)C(=O)[O-]"

HTTP/1.1 200 OK

Server: gunicorn/19.1.1

Vary: Accept

Cache-Control: s-maxage=30000000, max-age=30000000

Content-Type: application/xml; charset=utf-8

Date: Fri, 13 Feb 2015 11:10:13 GMT

Transfer-Encoding: chunked

X-ChEMBL-in-cache: False

Connection: Keep-Alive

X-ChEMBL-retrieval-time: 0.175734996796

<?xml version='1.0' encoding='utf-8'?>

<molecule><atc_classifications/><availability_type>-1</availability_type><biocomponents/><biotherapeutic/><black_box_warning>0</black_box_warning><chebi_par_id/><chirality>-1</chirality><dosed_ingredient/><first_approval/><first_in_class>-1</first_in_class><helm_notation/><indication_class/><inorganic_flag>-1</inorganic_flag><max_phase/><molecule_chembl_id>CHEMBL477889</molecule_chembl_id><molecule_hierarchy><molecule_chembl_id>CHEMBL477889</molecule_chembl_id><parent_chembl_id>CHEMBL477888</parent_chembl_id></molecule_hierarchy><molecule_properties><acd_logd>2.47</acd_logd><acd_logp>6.03</acd_logp><acd_most_apka>3.40</acd_most_apka><acd_most_bpka/><alogp>6.02</alogp><aromatic_rings/><full_molformula>C20H31NaO3</full_molformula><full_mwt>342.45</full_mwt><hba>3</hba><hbd>1</hbd><heavy_atoms>23</heavy_atoms><med_chem_friendly>Y</med_chem_friendly><molecular_species>ACID</molecular_species><mw_freebase>320.47</mw_freebase><mw_monoisotopic>320.2351</mw_monoisotopic><num_alerts>3</num_alerts><num_ro5_violations>1</num_ro5_violations><psa>46.53</psa><qed_weighted>0.23</qed_weighted><ro3_pass>N</ro3_pass><rtb>15</rtb></molecule_properties><molecule_structures><canonical_smiles>[Na+].CO[C@@H](CCC#C\C=C/CCCC(C)CCCCC=C)C(=O)[O-]</canonical_smiles><standard_inchi>InChI=1S/C20H32O3.Na/c1-4-5-6-12-15-18(2)16-13-10-8-7-9-11-14-17-19(23-3)20(21)22;/h4,7-8,18-19H,1,5-6,10,12-17H2,2-3H3,(H,21,22);/q;+1/p-1/b8-7-;/t18?,19-;/m0./s1</standard_inchi><standard_inchi_key>RLSXKIUQYFNFBI-PJZMSVRGSA-M</standard_inchi_key></molecule_structures><molecule_synonyms><synonym><syn_type>OTHER</syn_type><synonyms>(Z)-Stellettic Acid B Sodium Salt</synonyms></synonym></molecule_synonyms><molecule_type>Small molecule</molecule_type><natural_product>-1</natural_product><oral/><parenteral/><polymer_flag/><pref_name/><prodrug>-1</prodrug><structure_type>MOL</structure_type><therapeutic_flag/><topical/><usan_stem/><usan_stem_definition/><usan_substem/><usan_year/></molecule>mnowotka@candela:~/Documents/ci/curation_interface/trunk/src/curation_interface/chembl_webresource_client/chembl_webresource_client$

view raw curl.sh hosted with ❤ by GitHub

How long?

What about POST?

OK, so SMILES can be passed via GET, can POST still be used? Yes! For every single method you can use POST as well. This is important, as it is possible to create very long URLs, by chaining together multiple filters and other parameters, such us pagination and ordering. This is why all new web services methods (even those, which don't expect any SMILES), can be executed using POST. In fact, our updated Python client (blog post coming soon!), is using POST for almost everything. Just keep in mind, that in order to use POST to retrieve data, you have to add X-HTTP-Method-Override:GET header.

If the earlier discussion around SMILES encoding all seems a bit too complicated (hence the xkcd comic strip) or just too much hassle, you can always use POST. But remember you won't be able to share SMILES links in your blog posts or Skype conversations :(

Is using POST to retrieve data 'breaking the web'?

There was a recent discussion about this topic after Dropbox team announced (just like us), that they see some limitations in GET compared to POST and will start to allow POST methods to retrieve data (original article). There were some critical opinions about allowing POST access to data, stating that this is a poor API design. This is turn has triggered a long discussion on hacker news page, from which one comment is particularity important:

"I really like how the Google Translate API handles this issue. The actual HTTP method can be POST, but the intended HTTP method must always be GET (using the "X-HTTP-Method-Override" header)."

And this is exactly what we are doing, and we also believe this is the right way to use POST in order to allow retrieval of data from RESTful web interface.

The ChEMBL Team

Improvements in SureChEMBL's chemistry search and adoption of RDKit

Dear SureChEMBL users, If you frequently rely on our "chemistry search" feature, today brings great news! We’ve recently implemented a major update that makes your search experience faster than ever. What's New? Last week, we upgraded our structure search engine by aligning it with the core code base used in ChEMBL . This update allows SureChEMBL to leverage our FPSim2 Python package , returning results in approximately one second. The similarity search relies on 256-bit RDKit -calculated ECFP4 fingerprints, and a single instance requires approximately 1 GB of RAM to run. SureChEMBL’s FPSim2 file is not currently available for download, but we are considering generating it periodicaly and have created it once for you to try in Google Colab ! For substructure searches, we now also use an RDKit -based solution via SubstructLibrary , which returns results several times faster than our previous implementation. Additionally, structure search results are now sorted by...

The ChEMBL-og

Search This Blog