用于SOAP的WSDL和基于JSON的REST和REST的WSDL

Question

when a company wants to release a web services, does it release a separate WSDL for SOAP and separate for REST based web services or they are merged in the same WSDL? Can a WSDL only represent REST web services based on JSON (not XML) ?

Assume web services clients are Java based.

If SOAP and REST are merged in the same WSDL, does wsimport generates separate classes (for binding XML to Java objects) for SOAP and separate for REST?

Answer 1

You need WSDL 2.0 (or WADL) to describe REST service. Support for WSDL 2.0 is currently very limited and wsimport doesn't support it. I'm not Java developer but I think that wsimport is only for SOAP services (JAX-WS and it doesn't support WSDL 2.0 as well).

Edit:

Check this extension . It should allow you exposing JAX-WS service with JSON encoding. It should also expose "JavaScript proxy" for calling the JSON service. To more precisely answer your question - I don't think that you can describe REST service without WSDL 2.0 or WADL. So you cannot merge SOAP and REST service to single WSDL 1.1 supported by most stacks. For further reference about describing JSON service check this question .

Answer 2

Can a WSDL only represent REST web services based on JSON (not XML)

WSDL 2 can describe XML by defining the XML types using a schema. See this introduction on WSDL 2 for REST .

Although, TBH I've never written WSDL for REST before, I just publish the URLs and the schemas for the types.

Answer 3

Since the tooling isn't quite there yet, I doubt many are using SOAP and HTTP bindings in a single WSDL. Although both can be represented in a WSDL 2.0, and at the same time, since most folks rely on tooling to manage their WSDLs today (and the rest of the WS stack), they probably simply don't bother and leave their WSDLs alone.

Also, most REST people are building their clients by hand, rather than relying on tooling and WSDLs, so those folks aren't currently "missing" the tooling and support for this.

When the tools catch up on both the server and client side, then there will likely be more adoption in practice for HTTP service bindings in WSDL 2.0. Whether the idiom will be to conflate the to specs in to a single WSDL or not, remains to be seen.

If they want to host them on the same end points, then they likely will.