Hi Arturo!
/api/v1, query params and 40X responses all seem fine to me. I'd a couple
more operations: /login/logout, as being logged can yield different results
(i.e., searching pages), and may be a /pages/{page} operation, as that may
be one of the most called operations for the API.
cheers,
juan pablo
p.d.: still compiling the security issues I expect to send the e-mail to
private tomorrow
El mié, 28 oct 2026, 11:38, Arturo Bernal <[email protected]> escribió:
> Hi all,
>
> Following the discussion, I attached a first draft of the OpenAPI
> description to JSPWIKI-1310
> <https://issues.apache.org/jira/browse/JSPWIKI-1310>. It covers only read
> operations (search, suggestions, plugins) and nothing is implemented yet. I
> would like your opinion on three choices before any code: the /api/v1 base
> path, ordinary query parameters instead of the comma separated params, and
> real 401, 403 and 400 answers with a JSON body.
>
> Arturo
>
>
> On Wed, Oct 28, 2026 at 10:21 AM Arturo Bernal <[email protected]> wrote:
>
> > Hi Juan Pablo,
> >
> > Thanks. That direction works for me: an OpenAPI contract first, new
> > endpoints written against it, and the existing servlet and Ajax endpoints
> > moving there over time. I would still start by documenting what exists
> > today, so the contract has a baseline and we can see which endpoints are
> > worth moving first. I will
> > update JSPWIKI-1310 with this plan.
> >
> >
> > Arturo
> >
> >
> > On Wed, Oct 28, 2026 at 9:55 AM Juan Pablo Santos Rodríguez <
> > [email protected]> wrote:
> >
> >> Hi!
> >>
> >> Thanks for bringing this up. REST API is very much needed IMHO. I think
> >> the
> >> clearer path would be an openapi contract with new endpoints, and move
> >> current endpoints there over time. I suppose few top level jsps would
> >> remain, then.
> >>
> >> Regarding 3.0.1, yeah, should come ASAP, depending on devs time, of
> >> course.
> >> Problem is we're swamped with sec reports, and there are at least a few
> >> that need to be addressed before releasing :-/ I'll start a thread at
> >> private later today at private to summarize what's pending, so we can
> >> focus
> >> on that
> >>
> >>
> >> Cheers,
> >> juan pablo
> >>
> >> El mar, 27 oct 2026, 12:07, Arturo Bernal <[email protected]>
> escribió:
> >>
> >> > Thanks Ulf, I agree. MBeans need no new dependency and fit the wish to
> >> keep
> >> > the wiki light. A correction to my mail: the admin beans are already
> >> > registered as MBeans with the platform MBean server by
> >> > DefaultAdminBeanManager, so JMX is partly there. What is missing is
> >> > operational data, and I have not checked yet what the existing beans
> >> > expose. I will change JSPWIKI-1311 to this: first add MBeans with the
> >> > operational data that is missing, and document Jolokia for access over
> >> > HTTP.
> >> >
> >> > Micrometer or Prometheus could come later if somebody asks for it.
> >> >
> >> >
> >> > Arturo
> >> >
> >> >
> >> > On Tue, Oct 27, 2026 at 11:43 AM Ulf Dittmer via dev <
> >> > [email protected]>
> >> > wrote:
> >> >
> >> > > > 4. JSPWIKI-1311, metrics, a health endpoint and structured
> >> logging.
> >> > > > org.apache.wiki.management only has SimpleMBean, and there is no
> >> > > > Micrometer, Prometheus or health code.
> >> > >
> >> > > Rather than adding dependencies to handle observability, I think
> >> > > adding Mbeans with the desired information might be the simplest way
> >> to
> >> > > go. Though not as standardized (and thus usable by other
> >> > > languages/clients), I find them easy to query with a tool like
> >> VisualVM,
> >> > > which also allows to manipulate internals. It does require VPN
> access
> >> to
> >> > > the server, though, so as not to open up the JMX Remote port to the
> >> > world.
> >> > >
> >> > > HTTPS access to Mbeans can still be had using something like
> Jolokia.
> >> > >
> >> > > Ulf
> >> > >
> >> >
> >>
> >
>
