Usually it costs 3-5s to get the response. But sometimes it will cost about 8-10s.
Could you please explain which part during this query takes the most time? Is it the network? QOS? or the database inner query time? If it is the qos, could you please share me the estimate query time for a Crossref Plus tier?
Thanks for your message! What kind of query were you doing that returned results in 3-5s? Were there fewer terms in your query.bibliographic parameter? The more terms included in the query.bibliographic parameter, the greater the likelihood that your query will take more time for us to return results.
Faster, R-CNN:, Towards, Real-Time, Object, Detection, Region, Proposal, and Networks
So, the API is searching the bibliographic metadata for each of the 138 million plus records in our corpus for each of those words and then returning results ordered by the metadata that matches each and all of those search terms most closely (i.e., it’s an expensive query).
so, depending on the timing of this query, the slower response time might also be related to overall traffic on the pool.
If you can contact me at support@crossref.org, we can provide you with some additional details about the Metadata Plus service (and, thus, the Plus pool of the REST API).
There’s a couple of different options that might be more efficient than the REST API query we discussed above, but it depends on what you need from us (and/or what you are querying against):
I’m developing an APP that can be used to retrieve metadata for some paper PDF files. But I do not have the full reference text and doi of those papers. So I can only parse the PDF files to get the titles, DOIs of them. For a paper, if there is a DOI in the PDF, it is easy to get its metadata. But some papers have no DOI in their PDF files. So the only option is to do a query like this:
I tired to limit the rows. But sometimes I still need to wait for even 16s to get the query response.
Following your suggesstion, I tried the Simple Text Query. I found that I need to provide at least: the first author, title, and year, to get the DOI response. This doesn’t seem feasible in my scenario. And according to the API document, Simple Text Query is for human, not machine. I’m not sure I can do this Simple Text Query programmably.
Seems that there is no more efficient solution to my query. Anyway thanks for your suggestions.
I talked with Patrick Polischuk, the product manager responsible for metadata retrieval, and he reminded me that we do have some feature development on the roadmap that should fit this use case a lot better: [CR-555] - Jira. The work is just in the research and planning phase, as you can see from our public roadmap, but we’ll get there in the longer term.