i just came back to upload some new DOIs and it took me nearly an hour to get from the crossref homepage to the cross administration area. Surely there should be a large, obvious, link? I have now saved a link locally, but why is the site designed in such a user-unfriendly manner?
Hi Jeremy,
My apologies about the frustrating experience navigating our website. Itās true that the admin tool used for manual metadata uploads isnāt particularly obvious from our main website.
The truth is that relatively few Crossref members use that admin tool to submit metadata files. Those that are able to construct their own xml typically submit it programmatically using HTTPs POST. And, those that arenāt able to construct their own xml, either have it constructed/submitted for them by their journal management software, hosting platform, typesetter, or some other service provider; or, they submit their metadata by manually copy-pasting it into our web form.
So, this particular user experience problem for those members who are able to construct their own xml, but who upload via the admin tool web interface, just hasnāt come to our attention previously. I will pass that along to our product management team, who can consider how to make the link to the admin tool more easily findable.
In the meanwhile, Iād recommend beginning at our Documentation Site, rather than the main webpage.
-Shayn
2 Likes
(I apologize if Iām annoying you Shayn, but Iām gearing up our journal and I keep finding problems). The link you gave for the HTTPs POST appears to be incorrect. That involves posting to the same path doi.crossref.org/servlet/deposit, but that as is used by the admin tool, and it gives an HTML response. It also ignores the request header for content negotiation, so I couldnāt find a way to return a machine-parsable response at that API endpoint. Moreover, if the authentication fails it doesnāt respond with a 403 - it responds with a 200 response containing a login form. Thatās not useful for an API endpoint, but itās ok as a backend for the admin tool to manually submit a file.
I found documentation elsewhere that said to post to doi.crossref.org/v2/deposit using different parameters (usr, pwd, operation, mdFile). That is in fact the method used by the OJS crossref plugin (I read through the code), so I have to assume that this is the correct path. Iāve tested it and it appears to function as documented.
We donāt use OJS ourselves - in fact I am in the process of building an open-source alternative to OJS. The documentation site for HTTP POST appears to be pointing to the wrong thing.
Donāt worry about annoying any of us - weāre here to help!
The doi.crossref.org/v2/deposit endpoint is currently only supported for use by OJS.
doi.crossref.org/servlet/deposit is the endpoint for the admin tool, but itās also the endpoint for HTTPs POST use. If youāre getting an HTML response, that probably means thereās an issue with the way youāre sending your authentication credentials.
Thatās a known issue that weāre actively working on. When the login_id value is formatted incorrectly, there should be some more sensible response than returning the html source code for the login screen of the admin tool.
Can you tell me what youāre suppling for that login_id value? Or, if you donāt feel comfortable sharing that on the public forum, send it in an email to support@crossref.org
1 Like
I donāt think I can comment on that zendesk issue, but Iāll suggest one possible way to use the same endpoint for both a web form and a REST API is to use content negotiation. A browser will always send a header of āAccept: text/html, ā¦ā but an API call would send a header āAccept: application/xmlā to tell the endpoint what kind of response it wants. The servlet can then adjust the response based on whether it is talking to a browser or client code invoking an API. If authentication fails in the browser you can send the HTML you are sending now. If authentication fails in an API client, you should send xml with an appropriate error message. What Iām getting on that endpoint right now is HTML, which is pretty useless and hard to distinguish from an authentication error. Receiving an email is even less useful for an API 
, so we will either be polling or using the notification callback service.
Since you are responding with XML, it would be useful to point to the schemas for <doi_batch_response> or <doi_batch_diagnostic>. I couldnāt find them in the schema library. The examples for the notification callback service appear to use JSON, so once again a schema would be useful (in that case a JSON schema).