My company is using SOAP for web services. Despite my efforts to convince my peers to use JSON, we still ended up using SOAP. WSDL was one of the main reasons (another is their unfamiliarity with JSON). That kind of annoyed me.
I love JSON for its simplicity and lightweight, but I also like WSDL which provides the description of the data being transmitted. Is there such a description language for JSON? If not, how feasible and practical is it to have one?
You could come up with a custom description language, but the point of JSON is that
it's schema-less.
There is actually something called JSON Schema (Wikipedia page) - have a look at that.
Looks like you're looking for JSON Schema or WSDL 2.0? In the latter, you can request JSON by supplying the appropriate Content-Type header in the REST request; the former is more of a "static" description of data (like an XML Schema, say) than the full description of a service (like WSDL) but can be used for the other purpose to some extent.
When you say JSON, do you mean just the object format or do you mean RESTful services in general? I ask because JSON is really an alternative to XML, and both are ways of serializing data structures and not in themselves web-services.
SOAP's analog is REST (sort of) and you can conceptually use either XML or JSON with both of them, though there's no standard way of saying that you're going to use JSON for serializing a SOAP message as far as I'm aware.
WSDL can map conceptually to WADL for RESTful services, but that's not standardized at all. (I suppose you can use WSDL to describe REST and WADL to describe SOAP, but that'd be hard work; the two specs treat different parts of what is going on as important.)
FWIW, I write services that have both SOAP and REST interfaces, and the REST interfaces support both XML and JSON as data serialization schemes (except for one or two operations where the documents being passed were always in XML already). The key to doing this is to have a principled back-end API that is exposed via SOAP in one natural way and via REST in another; the logical model is identical, but the way you see it is different. This has the advantage of making tooling clients in a wide range of languages trivially possible (which was a strong requirement from the user community); we currently have Java, Ruby and Tcl clients. (The service is in Java with the CXF library, which makes it pretty easy to support both APIs in a single webapp.)