WSDL 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 clients decide how to deal with it.

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.

You're being downvoted because this project is a generator program which, as input, takes a specification of the API in JSON format. This JSON specification is what is being compared to WSDL because they serve the same purpose: to define the endpoints, arguments, and return values for a given API.

I agree with that, but I am correct in pointing out that the scope of this project covers things that WSDL does not, and in that sense it isn't like WSDL. When someone asks a question that can easily be answered in terms of differences I think it's completely reasonable to point those out.

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.

The comment you replied to said:

  > 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.