We recently finished a project that both consumed .NET WebServices (SOAP), produced Java WebServices (SOAP), and use REST-based library to provide a communication channel between 2 components.
Generating Java WebService client given .NET XSD/WSDL was a 5 minutes job. Ditto for the other way around: generating an XSD/WSDL from Java to be consumed by other parties was a 5 minute task (how the other party consumed it not of our concern).
OTOH, coming up with a good RESTful interface is proven to be very challenging. Some people coded up their REST interface to be like "/some/url/getInvoice", while others coded up their REST interface to follow Rails a bit more given their background. But sometime this second group that follows Rails convention were wondering how to implement the right REST interface for certain use-cases such as updating a boolean that is part of another bigger domain model object:
You say you "generated" the clients. What happens when you need to change your services in a way that changes the WSDL? If your types or parameters change, your clients won't work anymore unless they re-read the WSDL. With Java and .NET, that generally requires recompiling the clients and redistributing them.
That's what Roy's talking about when he says REST is about designing on a long term scale. A client that uses a RESTful API should be parsing and navigating the representations dynamically, which allows them to handle changes in the representation gracefully. The clients can never handle semantic changes to the API, but they can handle structural changes.
What do I mean by that? If you provide links for paging, and the link for the next page uses rel="next", that's the semantic meaning for the link. Your client has to hardcode the knowledge that it needs to find the link with rel="next" in order to go to the next page. But, it doesn't matter where that link may appear in the page, or what the url for that link happens to be. These are both structural details that can change over time without breaking your client.
Generating Java WebService client given .NET XSD/WSDL was a 5 minutes job. Ditto for the other way around: generating an XSD/WSDL from Java to be consumed by other parties was a 5 minute task (how the other party consumed it not of our concern).
OTOH, coming up with a good RESTful interface is proven to be very challenging. Some people coded up their REST interface to be like "/some/url/getInvoice", while others coded up their REST interface to follow Rails a bit more given their background. But sometime this second group that follows Rails convention were wondering how to implement the right REST interface for certain use-cases such as updating a boolean that is part of another bigger domain model object:
- What is the URL will look like?
- What kind of operation?
- What is the parameter?
- What is the return value?