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?
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.
(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 firstname.lastname@example.org
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_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).