Migrating from old "v2" API to new: a few questions

Dear developers and fellow users,
I am migrating my web app ELATE (see https://progs.coudert.name/elate) for visualization of elastic tensors (including those from MP) from the old “v2” API to the new. Previously I used two endpoints:

  • https://legacy.materialsproject.org/rest/v2/query to get elastic tensors for a specific material (identified through criteria and task_id). I have migrated that one to use https://api.materialsproject.org/materials/elasticity/?material_ids=
  • https://legacy.materialsproject.org/rest//v2/materials/{query}/mids for users to run simple searches/queries (like ZnO or Li-Fe-O)

I have two questions:

  1. in the first endpoint, the elastic tensor is returned with two representations: raw and ieee_format. Which one corresponds to the old field response["elasticity"]["elastic_tensor"]? I assume it’s the ieee_format one, but I would like confirmation.
  2. What is the correct endpoint in the new API for searching materials IDs corresponding to a simple query, like I was doing before? I read through the docs but I’m not sure there is a simple way to do that.

Thanks for any help you can give.
FX

@fxcoudert thanks for reaching out! @munrojm should be able to confirm which representation is used. As for your second question, we don’t allow free-from MongoDB-style queries to be sent to our servers anymore. All queries are now covered by combining query parameters such as chemsys and formula in the summary endpoint, see https://api.materialsproject.org/docs#/Materials%20Summary/search_materials_summary__get HTH

@fxcoudert
(1) Yes I believe that is correct.
(2) Depends on your query. If you are querying across multiple properties you will have to use summary, else you might be able to get away with just querying materials or elasticity. If you tell me the exact fields you want to use, I can give you a better answer.

– Jason

Thanks for your answers. I ended up using summary, with their chemsys= or formula= depending on what the user passes to ELATE. It seems it will be the closest to the old behaviour.

Now I have trouble because my connections from ELATE to MP fail on the web server, even though they work for me locally. But that’s for me to debug :slight_smile:

Do you have an error message? It might a CORS issue and I’d have to explicitly add your website to our CORS config to allow requests from your site.

I don’t get an explicit message except a timeout:

HTTPSConnectionPool(host='api.materialsproject.org', port=443): Max retries exceeded with url: /materials/elasticity/?material_ids=mp-2133&&_fields=elastic_tensor,material_id,formula_pretty (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7f51fe2936d0>, 'Connection to api.materialsproject.org timed out. (connect timeout=4)'))

If it were a CORS issue, what would be the expected error?

(The call is not done in the browser, it’s done on the server side through python, so I don’t think it can be a CORS issue, but I may be wrong…)

Yes, if you’re using server-side python to make the request, CORS is not the issue. Are you using the mp-api python client or are you manually creating the request using the python requests package? The request looks ok and should work but it might be that your server isn’t configured/allowed to reach api.materialsproject.org.

Also, please refer to our latest terms: https://materialsproject.org/about/terms. We’d prefer for your users to create MP accounts and use their own API keys. Are you currently using an API key from one of your own MP accounts to have the app connect to the MP API?

As @mkhorton said in the other thread, it might be worth thinking about porting your app into MP officially since it seems to provide functionality that could be valuable for MP users in general. We make sure to give appropriate credit, of course. MP apps are written in python (Plotly Dash), so it should be pretty straight-forward for you to port it and for us to integrate it. @ruoxiyang can provide guidance and help you with the process if you’re interested.

Maybe we should continue this discussion by email? I can be reached here: François-Xavier Coudert | Senior Researcher at CNRS & PSL University

Users of ELATE don’t register. I believe I am complying with the terms of use: I am not scraping (requests are made one at a time, and actually at a very low rate, and I have some safeguards in place to avoid the use of ELATE for scraping as well). I am not sharing the API key (this is why the request is made from the server, and not from the browser): the ELATE user cannot intercept or obtain my API key. I give appropriate credit on every page to the Materials Project, with links as well.

I thought this was reasonable use of the service, and I think you did too, when links to ELATE were added to all pages on the Materials Project website. Obviously, if you disagree, please let me know and I will remove ELATE integration. I think, however, it would be bad for users — and I don’t think there has been any misuse.

Re. requiring users to register: ELATE does not have a concept of registered users, it’s completely open, so I don’t think that would work easily.

Re. integration of ELATE functionality into MP, why not. I’d be happy to discuss it.

Sounds great! Thanks for being diligent with following our terms. We’re definitely in favor of supporting open-research apps like yours as much as we can. I’ll reach out per email to discuss the option to port your app into MP.