4 ms·

I'm reading the API docs https://enterprise.wikimedia.com/docs/ https://enterprise.wikimedia.com/docs/ And they don't have an OpenAPI spec available to downloa

I'm reading the API docs https://enterprise.wikimedia.com/docs/ https://enterprise.wikimedia.com/docs/ And they don't have an OpenAPI spec available to download? So they seriously expect developers to just manually write their own client code by reading and translating those example CURL commands by hand??! Seriously it's 2024! Not having a spec to download and insepct for any API is a sign of incompetence. When tools like Postman or https://github.com/OpenAPITools/openapi-generator-cli https://github.com/OpenAPITools/openapi-generator-cli exist and save hours of time, you can't seriously expect devs to write all this connecting code by hand anymore.

michaelt 2y ago
If only there was some code generation technology that could take in human-readable specifications, not just machine-readable ones....
croes 2y ago
Then create one, share it and save us some time.
- trustno2 2y ago
  so enterprise very wow
chuckreynolds 2y ago
link at bottom of https://enterprise.wikimedia.com/docs/ https://enterprise.wikimedia.com/docs/ page
schoenobates 2y ago
Bottom of the page ... https://api.enterprise.wikimedia.com/spec/spec.yaml https://api.enterprise.wikimedia.com/spec/spec.yaml
krainboltgreene 2y ago
> And they don't have an OpenAPI spec available to download? So they seriously expect developers to just manually write their own client code by reading and translating those example CURL commands by hand??! This is baby work to literally every programmer I know.
- causal 2y ago
  Not to mention that if it's really needed, the LLMs this is made for also excel at converting CURL commands to whatever spec pretty trivially. I've used them this way on a few occasions.
- miffy900 2y ago
  It's also a solved problem that literally no human should have to bother with anymore. Like it was solved with SOAP APIs back in the 2000's. Not to mention the fact that documentation is still always hand-written - which can have mistakes or typos in it, then downstream developers will have to translate that into hand-written client code, which can also have those same mistakes or bugs in it. And when the mistake is corrected, the dev needs to go back to where the correction was made in the docs, re-read and interpret the correction and then correct their client code. With API specs and code generators that entire process is automated now. Now imagine bringing together approximately 6 different APIs into a single app, 5 have API specs while 1 doesn't. Now 80% of your time is spent on that 1 API where you have to read the docs to keep your client code up to date. Oh that 1 API vendor doesn't bother letting you know when their API is updated! So you have to F5 their website every week! This is literally my life right now. Anyway, in this case, it was my mistake not to read until the very bottom where they had an OpenAPI yaml spec link there.
  - krainboltgreene 2y ago
    > It's also a solved problem that literally no human should have to bother with anymore. This is such a hilariously wrong statement I can't even begin to approach the rest of this comment with any serious attention.
rattray 2y ago
If someone from the wikimedia enterprise team is here and interested in providing those SDKs, but finds the openapi generator linked above to be lacking, I'd be happy to help (my company does the SDKs for OpenAI, Cloudflare, etc). I've been a monthly donor to wikimedia for a long time and it'd be quite a privilege to support them with nice API wrappers too. Email in profile.

michaelt 2y ago

If only there was some code generation technology that could take in human-readable specifications, not just machine-readable ones....

croes 2y ago

Then create one, share it and save us some time.

trustno2 2y ago
so enterprise very wow

chuckreynolds 2y ago

link at bottom of https://enterprise.wikimedia.com/docs/ https://enterprise.wikimedia.com/docs/ page

schoenobates 2y ago

Bottom of the page ... https://api.enterprise.wikimedia.com/spec/spec.yaml https://api.enterprise.wikimedia.com/spec/spec.yaml

krainboltgreene 2y ago

> And they don't have an OpenAPI spec available to download? So they seriously expect developers to just manually write their own client code by reading and translating those example CURL commands by hand??! This is baby work to literally every programmer I know.

causal 2y ago
Not to mention that if it's really needed, the LLMs this is made for also excel at converting CURL commands to whatever spec pretty trivially. I've used them this way on a few occasions.
miffy900 2y ago
It's also a solved problem that literally no human should have to bother with anymore. Like it was solved with SOAP APIs back in the 2000's. Not to mention the fact that documentation is still always hand-written - which can have mistakes or typos in it, then downstream developers will have to translate that into hand-written client code, which can also have those same mistakes or bugs in it. And when the mistake is corrected, the dev needs to go back to where the correction was made in the docs, re-read and interpret the correction and then correct their client code. With API specs and code generators that entire process is automated now. Now imagine bringing together approximately 6 different APIs into a single app, 5 have API specs while 1 doesn't. Now 80% of your time is spent on that 1 API where you have to read the docs to keep your client code up to date. Oh that 1 API vendor doesn't bother letting you know when their API is updated! So you have to F5 their website every week! This is literally my life right now. Anyway, in this case, it was my mistake not to read until the very bottom where they had an OpenAPI yaml spec link there.
- krainboltgreene 2y ago
  > It's also a solved problem that literally no human should have to bother with anymore. This is such a hilariously wrong statement I can't even begin to approach the rest of this comment with any serious attention.

rattray 2y ago

If someone from the wikimedia enterprise team is here and interested in providing those SDKs, but finds the openapi generator linked above to be lacking, I'd be happy to help (my company does the SDKs for OpenAI, Cloudflare, etc). I've been a monthly donor to wikimedia for a long time and it'd be quite a privilege to support them with nice API wrappers too. Email in profile.