But, to do that I need a format using which people can define their API. I used JSON and only supported the elements that I needed to generate the client libraries.
But, to do that I need a format using which people can define their API. I used JSON and only supported the elements that I needed to generate the client libraries.
EDIT: Since I was down-voted for whatever reason, I'd like to rephrase. WSDL is a standardized language for defining web services. It's not a tool in itself for generating client code, and what I said was meant to point out that that's the obvious difference between this and WSDL. A description written in WSDL can both be used to generate client APIs and skeleton code for the server itself, but isn't the generator itself, just like C isn't gcc.
Perhaps my parent intended for the question to be rhetorical, with the implied answer being "Yes, I'm silly for reinventing the wheel" in which case the differences between this project and WSDL are an also an obvious defense of it.
> Right, the format affords generic description documents
> from which to generate client code. This seems very
> similar in spirit to WSDL. No?
The word "this" in the second sentence clearly refers to "the format". To reword the parent: > The JSON format used by this project seems very similar
> in spirit to WSDL. No?
So while you're correct that the entirety of the project (JSON format + code generation) is greater in scope than just WSDL, you took exception to a claim the parent did not make. You could equally have said: > The JSON format used by this project is not a method in
> itself for actually generating the client code, though.
> It's simply a (barely) machine readable description of
> the API from which [the project's code-generating client]
> decides how to deal with it.
I don't think anyone thought otherwise.