@Jan Range in the docs meeting I just mentioned the API docs you generated using OpenAPI and https://readme.com
Do you still have an example up somewhere?
Of course, you can find the example here - https://test-dv.readme.io
wow, that looks great!
I agree, its really nice! You can also test/run the endpoints
This non-developer is very happy to see that :sweat_smile:
this looks so cool! love the ability to edit the variables in an API call directly from the interface, makes that really clear for people. we discussed having this kind of API docs in the docs meeting today, to remove manual error/inconsistencies and have more automated updating.
It's extremely cool. Thanks, @Jan Range! ![]()
I'm slightly bummed that if I click "try it" at https://test-dv.readme.io/reference/getversioninfo it complains that I need an API token. It's an open API that doesn't require auth: https://demo.dataverse.org/api/v1/info/version
Yes, that is a bit annoying. This stems from the OpenAPI specs though, because I have added the TokenAuth globally to use endpoints that do require auth. You can add the security scheme per endpoint though and then it shouldnt be mandatory anymore for all of them
I see. @Juan Pablo Tosca Villanueva do you happen to know what we should add on the Java side?
I will figure it out, but will it work even if it is set globally ? @Jan Range ?
Like if you set it globally and then some endpoints are just marked as secured
I wonder how it will work or should work with endpoints that return different things depending on auth
We already put @AuthRequired on all the endpoints that require auth, if that helps.
@Juan Pablo Tosca Villanueva yes you can define a global auth scheme and then assign it to each endpoint that requires it. It is also possible to render auth optional, using the following on an endpoint:
security:
- {}
- api_key: []
Jan Range said:
Juan Pablo Tosca Villanueva yes you can define a global auth scheme and then assign it to each endpoint that requires it. It is also possible to render auth optional, using the following on an endpoint:
security: - {} - api_key: []
I have to start making merits so @Jan Range mentions me on the next DV community meeting :sweat_smile: , would this be what we need for this to work correctly? "https://github.com/IQSS/dataverse/pull/10971" sample:
post:
tags:
- saveAuxiliaryFileWithVersion
summary: Save auxiliary file with version
description: Saves an auxiliary file
operationId: Access_saveAuxiliaryFileWithVersion
parameters:
- name: fileId
in: path
required: true
schema:
format: int64
type: integer
- name: formatTag
in: path
required: true
schema:
type: string
- name: formatVersion
in: path
required: true
schema:
type: string
requestBody:
content:
multipart/form-data:
schema:
type: string
responses:
"200":
description: File saved response
"403":
description: User not authorized to edit the dataset.
"400":
description: File not found based on id.
security:
- api_token: []
@Philip Durbin π
We would need to add the annotation Β @SecurityRequirement(name = "api_token") to each secured endpoint and then disable the global one is my guess.
I think we also need to define the:
"securitySchemes" : {
"api_key" : {
"type" : "apiKey",
"name" : "api_key",
"scheme" : "api_key"
}
}
Still trying to figure it out how to do it for microprofile
I am so close...
2 messages were moved here from #dev > Zed by Philip Durbin π.
@Juan Pablo Tosca Villanueva that looks promising! Looking forward to the result
@Jan Range he's talking about the hub, not Dataverse: https://github.com/IQSS/dataverse-hub
I wouldn't want to get your hopes up. :sweat_smile:
But it may pave the path to do this on DV one day in the future :wink:
I am/was looking at this today, the documentation I made for the hub was done with SpringDoc (to generate) and Swagger tags to define the documentation, it seems that smallrye (generator) favors the use of the eclipse microprofile tags for definition of the documentation. Which makes it awkward because A LOT of the annotations share the same exact same name, and let's say 95% of the properties but there are small differences that make them not compatible between the two of them.
For example this issue is something that is also preventing me from defining this global security schema: https://stackoverflow.com/questions/78701162/generating-openapi-with-eclipse-microprofile-annotations-how-to-configure-globa
I probably could try to make a demo with SpringDocs + Swagger annotations but I am not sure if any of you guys have hard set opinions on one or the other... (looks at @Oliver Bertuch) :eyes:
TLDR: [Spring docs + Swagger tags] vs [Smallrye + Microprofile]
We could also look at a third option that is removing the generator and see what payara likes...
Maybe we could experiment in a couple branches with different solutions.
How does this look?
/info/applicationTermsOfUse:
get:
tags:
- info
operationId: Info_getApplicationTermsOfUse
parameters:
- name: lang
in: query
description: Two-character language code.
required: false
schema:
type: string
example: en
responses:
"200":
description: Application Terms of Use (General Terms of Use) that must be
agreed to at signup.
That's from this commit: https://github.com/IQSS/dataverse/pull/11422/commits/26b9be752c0603ef7689244b5d2bab4c1e88f8de
@Jan Range @Juan Pablo Tosca Villanueva ^^
Last updated: Nov 01 2025 at 14:11 UTC