Which is the better approach to developing web services; contract first or contract last?
What are the advantages and disadvantages of each?
Which do you have experience with?
EDIT This question is about the implementation of a web service (read: SOAP) The question is whether the implementation classes should be coded first and the WSDL and XSD schema generated from that (contract last) or the WSDL and XSD schema written first and the implementation classes generated (contract first)
Contract-first means you design the way your services are going to communicate with each other before you design the services themselves. Contract-last is the other way around – you design how your service is going to work, then make one or more methods available as the interface for other services.
The contract first approach is a way of designing and developing API's starting from a contract. Using the openAPI convention you can design your API and share it with your consumers and developers.
There are two ways of building SOAP web services. We can go with a top-down approach or a bottom-up approach. In a top-down (contract-first) approach, a WSDL document is created, and the necessary Java classes are generated from the WSDL.
In the contract-first web service, the “contract” (a WSDL definition of operations and endpoints and XML schema of the messages) is created first, without actually writing any service code. In the contract-last web service, existing logic is “exposed” as a web service and the contract is created at the very end.
Contract-first is the generally accepted 'best practice.'
It makes you be very clear with both the producer and consumer of the service exactly what is needed and what is expected. This becomes especially important when you start trying to convert java types -> xml types. You're also able to reuse schemas across different web service.
I've used both approaches. My suggestion is to use contract first schema, but code first WSDL.
Writing a WSDL file has a lot of weird nuances like bindings, ports and such. I'd rather have this done by tools rather than by hand. There are tools to help do this, but none of them are simpler than
@WebService public ...
At the very least you can verify your deployment.
For the schema, I suggested contract first because the XML Schema language is far richer than what you can describe in Java. An example I usually give is showing that XML Schema can restrict the size of a string and apply a regular expression pattern. Doing that in Java and annotations looks a bit messier.
Another advantage of doing the schema as contract first is the presence of tools to convert your schema file into HTML documentation.
The XJC tool can generate the requisite class files. However, I would only recommend doing that at start.
In the end you should take the generated WSDL file and work with that instead. That way you can use wsimport and verify that the whole thing from WSDL to Schema is valid.
You can deploy with the WSDL file by using the wsdlLocation attribute in your @WebService implementation and the application server will fix the binding data for you when users request the WSDL from the server, but you still retain your annotations. Otherwise your annotations will not appear on the requested WSDL files.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With