(Please set yourself as task assignee of this session)
- Title of session: The Future of MediaWiki APIs
- Session description: This session will start with an overview of the Foundation's plans for improving the MediaWiki APIs (REST, action, and beyond). Then we would like to hear from community members what they thing of the plan, if they have any concerns or ideas.
- Username for contact: HCoplin-WMF ; DKinzler_(WMF)
- Session duration (up to 90min): 60 minutes
- Session type (presentation, workshop, discussion, etc.): Presentation + Discussion
- Language of session (English, Arabic, etc.): English
- Prerequisites (some Python, etc.): Familiarity with the existing suite of web API offerings (eg: Action API, MediaWiki REST, WME, etc) is preferred, but not required.
- Any other details to share?: In addition to this session, HCoplin-WMF will be holding open office hours to discuss developer pain points, opportunities, and other API feedback with anyone who would like to engage 1:1 instead of in a group setting.
- Interested? Add your username below:
Notes ==**
- Reminder of WE5
Building understanding, where we are going and next steps.
- Our content is free, infrastructure is supported.
We view APIs are more responsible queries that we want people to use.
- Priortiise humans reading the content, supporting developers communities for wider range of opportunities than WMF can offer
- Creating mechanisms for API traffics
- Better policies for attribution
FROM SLIDES
- Focus is on feeding our developer community.
- Developer satisfaction survey results- users are generally satisfied. but want modern and consistent experiences.
- We are not reaching out to engage new developers as effectively as we should.
- Most people feel the API is adequate, but there is strong confusion because of issues of documentation. Improving experience is the focus for WE5
--Share dreflections on slide from the survey feedback
KEY AREAS FOR REFLECTIONS
Onboarding & Documentation
- Million options, I only know to use one, but that is the only one I was taught to use.
- Got a lot better at API since there is chatGPT.
- We are not necessarily serving the LLMs very well.
-Unexpected behaviour- request for 100 objects and get only 2. Unintuitive at the beginning to work with.
- Unexpected functional gaps like Merge, it's tough to approach. Started developing outside the wiki before the wiki. I was expecting the same corporate environment, but finding the documentation was not easy (refers to Wikibase)
-allowing developers to allow create new experiences on top of it. We see the amazing work being done, but want to make it easier for the newcomers.
Possible solutions
-OpenAPI specifications for all API
-Consistent Sandboxes
-User Guide for common scenarios
-Clarify usage for generated vs dynamic docs
-API Modules
--At Hackathon, someone built an interactive API visualisation using Codex, not perfect, but a great start!
Managed to internationalise it (available in multiple languages), hopefully it is expected to make it more accessible, especially for people who don't speak English
Questions
Q. Is API itself in multiple languages, or the documentation?
--Documentation
- Swageer UI+ does not offer internationalisation, so codex attempt was exciting.
Q. Are we trying to open-source the internationalisation & visuatisation all?
--No, unless you are using translate wiki, not sure if it applies to all.
Q. Is there something that validates the response structure?
-Yes, as part of the CI process, every time we purge and launch code, it will check for errors and responses.
The action API experiment is a hack, we do full validation of the request, we don't do validation of response in production. Full validation is for large infrastructures.
Q. API modules....
Start moving towards federal API extensions, self-manage extensions. and contain all that in a module.
If we have everything in one spec, it will be a different spec in every wiki.
Simplification & sustainability
SLIDES
Questions
-Discoverability, we have a lot of different ways of doing it.
-Things are inconsistent
-Incredibly robust- helpful sometimes, but not always.
--Simplified alternative App performance would be sufficient for wiki. We have adjacent format Verion 1 & 2
- Connect with Molly
-Figuring out how we can better match user experience and cater to user expectations. Larger teams with APIs make other products. There are still many things accross connections that still can't do the APIs. There is no API for how Wikidata gives you text.
-API problem and page is the first page, then Mediawiki REST API, Wikimedia REST API, don't know if they are sma or different. I want to get to the documentation as soon as possible, to help clarity.
- We will also support different APIs in the same view. It will be a one stop shop for all API documentation.
SIMPLIFICATION IDEAS from SLIDE
Questions
-Thoughts on running BOTs or accessing APIs without authenticating?
--Offers better access if authenticated BOTS
--Documentation for every API includes authentication
--Use APIs for making tools to explore data, so it makes sense to authenticate. I have never used the authentication, as I am not editing.
-Don't usually login for Toolforge- when you are logged out, it is a lot faster, and other is potential to lose private information, tracked history of login.
--The idea is that we will not require authentication always, we understand if it is to test a quick concept, that should be okay. Additional scenarios where you are logging in from a user account, you don't need a full-blown account. There are benefits to giving us information on user agency.
In future, we want to be able to enforce user limits accross all areas, for that we need this information. Risk is that someone can use your UIA??
We don't have time to be redundant. If they don't have time to authenticate, they won't. Its important to make our APIs clearer. How do we differentiate an abuser? User agents can be falsified.
UI strings are being spoofed!! Agents are spoofing each other's UIs.
Sustainability
SLIDES
Communication & Community
SLIDES
In general, we get people a heads up and communicate. But some changes are sudden, and we need to work on standardisation around communications, warnings, etc.
Our community is huge but scattered in a lot of different places. How do we ensure we reach the right people at the right time?
Questions
-It's funny to pretend I don't know anything and then find APIs
-Who here has asked a question about another wikimedian?
--Almost everyone in the room!! Find that in Discord?
It will be beneficial to have clarity on community details and also details on which community to reach out to and when.
Timeline?? 3 days?? A year?
What is available to people entering the community and who to engage with?
How do you want WMF to engage with the community?
How do you want to hear about changes and APIs?
Identification and observability
SLIDES
-Developer authentication,
--to prioritise human access, protect the community.
--To form data-driven decisions.
WE5.2 from the Annual Plan is available on Meta for feedback
-Key outcomes from SLIDES
Let us hear from you! Engage, share- So that we can build the future of these APIs together.