4 ms·

We used to have things called WSDLs and XSD schemas that made it _extraordinarily_ easy to make remote calls. Granted, a bunch of ding dongs never loaded their

We used to have things called WSDLs and XSD schemas that made it _extraordinarily_ easy to make remote calls. Granted, a bunch of ding dongs never loaded their own WSDL to look at it, creating a bad rap. We do have: * WADLs: https://en.wikipedia.org/wiki/Web_Application_Description_Language https://en.wikipedia.org/wiki/Web_Application_Description_La... * JSON Schema:https://json-schema.org/learn/miscellaneous-examples https://json-schema.org/learn/miscellaneous-examples And when they are available they're incredible, but nobody uses them.

Groxx 1y ago
Swagger/OpenAPI has been reasonably popular for a while: https://swagger.io/docs/specification/v3_0/about/ https://swagger.io/docs/specification/v3_0/about/
duttish 1y ago
Json schema is great, we used it at my last job and I've built a fuzzer generating data based on it. So the data passes basic validation, but possibly crashes the backend afterwards. Found lots of problems the first run.
marcosdumay 1y ago
If you ever tried to read an actual WSDL file, you'd have noticed it was not great. Yes, having an API type declaration is really important. And yes, somehow a lot of people just don't use those things. But the WSDL was one of the worst standards for that in all times. (And also, it inherited all of the shitness from XML, even the allowing non-deterministic processing and side effects while reading the file.) Anyway, I'm not really disagreeing on your main point. Read the JSON Schema docs, people, use it.
- exabrial 1y ago
  > Granted, a bunch of ding dongs never loaded their own WSDL to look at it ...
liampulles 1y ago
I think one can define a good API or a bad API using WSDLs (as with most commonly used schemas), but I have to say my experience with consuming WSDLs has universally been the latter. "My theory" is that the ease at which one can turn a function into an exposed, documented API is inversely proportional to the likelihood of it being a quality API. I think automagic annotations which turn functions into JSON APIs obey the same principle, for what its worth.
- exabrial 1y ago
  > that the ease at which one can turn a function into an exposed, documented API is inversely proportional to the likelihood of it being a quality API. I guess we'll just call this "liampulles postulate of apis"

Groxx 1y ago

Swagger/OpenAPI has been reasonably popular for a while: https://swagger.io/docs/specification/v3_0/about/ https://swagger.io/docs/specification/v3_0/about/

duttish 1y ago

Json schema is great, we used it at my last job and I've built a fuzzer generating data based on it. So the data passes basic validation, but possibly crashes the backend afterwards. Found lots of problems the first run.

marcosdumay 1y ago

If you ever tried to read an actual WSDL file, you'd have noticed it was not great. Yes, having an API type declaration is really important. And yes, somehow a lot of people just don't use those things. But the WSDL was one of the worst standards for that in all times. (And also, it inherited all of the shitness from XML, even the allowing non-deterministic processing and side effects while reading the file.) Anyway, I'm not really disagreeing on your main point. Read the JSON Schema docs, people, use it.

exabrial 1y ago
> Granted, a bunch of ding dongs never loaded their own WSDL to look at it ...

liampulles 1y ago

I think one can define a good API or a bad API using WSDLs (as with most commonly used schemas), but I have to say my experience with consuming WSDLs has universally been the latter. "My theory" is that the ease at which one can turn a function into an exposed, documented API is inversely proportional to the likelihood of it being a quality API. I think automagic annotations which turn functions into JSON APIs obey the same principle, for what its worth.

exabrial 1y ago
> that the ease at which one can turn a function into an exposed, documented API is inversely proportional to the likelihood of it being a quality API. I guess we'll just call this "liampulles postulate of apis"