I am tasked with creating a layer in Java/Spring that consumes web services from a couple different providers. These services define specific request beans but the end points do not publish XSD information.
What would be the best way to generate the artifacts required to consume these services? It seems building our own request objects is not the best way of doing things.
REST services do not offer XSD as the WSDL of a traditional SOAP service. Some REST frameworks offer WADL, or the may user Swagger.io to describe the service, or expose documentation like Spring boots actuator /docs.
If there is no such documentation, and you can't get the source code for the system you are integrating with, I recommend that you build your own set of Java POJOs so you can interface with the service in a typed manner.
I have done that for multiple systems that expose (online) documented REST services, but do not provide a set of DTO that you can use when consuming them.
Related
One problem that continuously comes up at my workplace is creating clients for Java rest services that we create. We have 4 different programming languages to support and it is costly to create clients for each programming language. Often this means our web services aren't available in a cross platform manner since we rarely have time to build all of the clients.
SOAP provides this type of discovery and machine created client mechanism based off of tools that consume WSDL but our architectural direction is to write REST based services in Java instead of SOAP services.
We would also prefer not to write WSDL documents by hand that expose these REST web services. In a .NET environment, WCF and ASMX web services automatically create the WSDL for consumption in other applications, but this is not a direction my team is allowed to pursue.
Can this be done in some fashion for a Java based REST service?
How can this be done without having to invest a lot of manual labor?
We're currently using spring controllers but might be able to argue for a different Java framework if it provides better velocity.
Jersey (JAX-RS implementation) has support for WADL. You can use Jersey to automatically generate a WADL and there is also some support for generating Java clients from the WADL.
That's for Java, and I don't know if it's more than basic support, but I doubt you can pull it off for 4 different programming languages.
You might want to read these first though (tl;dr: REST is more than a CRUD style Web API and is different than SOAP):
Do we need WADL?
Why the slow WADL uptake?
You may want to check third party tools like swagger (http://swagger.io/) and mashery. I know swagger has support for client generation.
I am new to web services in Java.
In SOAP web services, we have wsdl that tells us about the services like the operations etc. but in REST, we don't get wsdl.
So, my question is if someone wants to know the service details, then how that can be found in case of REST web services.
SOAP introduced WSDL to describe services, which can automatically be discovered and integrated with a mechanisms like UDDI. In reality SOAP is used just as hardcoded RPCs. If you use REST, many details like exceptionhandling, operation types, idempotency are handled using well known HTTP mechanisms. The only thing you need to know is the payload encoding. If you use XML, you may use XSDs to describe the services, if you use JSON you need to handle this on your own (its a lot simpler). The structure of your URLs should be designed so its intuitive enough, to be described in a one paged readme file.
To cut a long answer short: WebServices were so complicated you need a lot of boilerplating, REST services should be so simple, that a developr does not have to redefine and redocument the basics.
With REST there is no single established way to achieve this yet, however there are couple of options emerging:
Swagger http://swagger.wordnik.com/ - Inspects annotations in your source code (supports web frameworks JAX-RS annotations, Spring annotatins, Play2) and generates a JSON document describing your APIs. This JSON document can be displayed as an interactive web page as end user documentation using swagger-ui.
Json Home https://datatracker.ietf.org/doc/html/draft-nottingham-json-home-02 - Specification for a JSON document that describes your RESTful APIs
WADL http://en.wikipedia.org/wiki/Web_Application_Description_Language
In our application we have an Adobe Flex client that communicates to our Java/Spring backend via a facade (using AMF) that is exposed via Spring.
Any recommendations on how I could leverage this facade to make remote calls from iOS? Note that I would prefer backend frameworks that would be reusable from other clients (Android, etc).
I hear about JSON & RESTful web services. Would there be a way to rather easily get existing facade services to be exposed as RESTFul web services that uses JSON for object serialization?
Or would you recommend something different?
Any information and/or pointers will be appreciated!
Update:
So we have one option so far for this: JSON requests and responses via Spring
Anybody want to suggest any other ways?
Spring supports JSON requests and responses (see for instance, this article from the Spring In Practice blog), largely through the use of annotations.
While I don't think that it is likely that you'll be able to go through your existing AMF facade, I think that it should probably be pretty straight-forward to create a JSON-over-HTTP facade using the same underlying Spring controllers (assuming that you're using Spring MVC).
Edit: Whether the JSON-over-HTTP facade that you create is truly RESTful depends largely on your implementation.
I am new to consuming web services. I am trying to consume a SOAP service. This is currently in the test environment. What I have done is
Use wsdl2java to generate a wsdl that I have copied to my domain folder.
Use the API to send requests and receive responses.
What concerns me is do I need CXF or Spring WS to wire the service or is what I have sufficient. I am asking this because I have seen elsewhere like
What I don't get is where I would generate property when environments are switching from development to QA to production. And do I need to use CXF or Spring WS or are the annotated classes (#WebServiceClient sufficient) to consume the SOAP service. Basically, how to connect to different endpoints.
I apologize if this is rudimentary question. Thanks.
Spring-WS and Apache CXF are primarily useful for creating web-services. They are alternative web service implementations to the one that ships with Java6.
You can use them for writing clients, but there's not really much point, unless you're really keen on the alternative API that those provide.
The standard JAX-WS artifacts generated by wsdl2java should be perfectly sufficient for what you need.
As for your second question regarding how to target different prod/QA endpoints, you should ask a separate question for that, with full examples of what you have.
I am building websites in spring MVC. as there are many spring projects , i wanted know what will be scenario when spring web Services is used for.
i mean what can be done with that. Do i really need it for ecommerce site
Your question is really about "web services". For a layman's explanation of what it is all about, read this Wikipedia article.
There are a number of related acronyms that get bandied about:
SOAP (Simple Object Access Protocol) is a protocol for sending requests to a service and getting back a response. The messages are encoded in XML, and send over HTTP.
WSDL (Web Services Description Language) is a service description language for SOAP-based services. It does things like specify what is in the messages, and how the messages are bound to services.
SOA (Service Oriented Architecture) is essentially a system architecture in which the system consists of lots of SOAP services (and others) described using WSDL.
(The proponents of SOA talk about "design principles", but in my cynical view is that this is just a repackaging / recasting of stuff that people have been doing for 20+ years under other names.)
Do i really need it for ecommerce site
Ask your customers. Ask the people whose systems your system will be interfacing with. Ask the vendors whose components you intend to embed in your system.
If you have to use WS then what extra facility it will give
If you have to use WS (e.g. because your site needs to talk to other services that require WS), then you have to. That is sufficient justification.
If you don't have to use WS, then you need to balance the advantages of using WSDL + SOAP against the advantages of some other approach to implementing your web APIs. An SOA expert will probably say use SOA; an AJAX expert will probably say otherwise. And there are other remote procedure call technologies around ... if you really need that kind of thing.
WSDL + SOAP certainly does have some advantages; e.g.
machine readable specifications for your web APIs,
possibility of validation of messages against XML schemas,
an ecosystem of existing WSDL services,
adoption in some sectors of IT.
But it has downsides also; e.g.
WSDL + SOAP have a significant learning curve compared to some alternatives,
XML is a heavy-weight encoding scheme - relatively expensive to parse,
SOAP only pretends to be type-safe (compared with say CORBA / IIOP),
SOAP is not usually used* in browser-based clients; JSON or plain XML are commonly used for AJAX apps,
many people think SOA is over-hyped and steer clear.
* However, it can be used; read these IBM DeveloperWorks Articles.
My advice (FWIW) if your system is primarily a website, doesn't need to talk to SOAP services, and doesn't need to provide a SOAP service API for others .... don't bother. You can always add SOAP service APIs later if you need to.
Spring Web Services is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
More here : Spring Web Services
How to use Spring Web Service : Spring WS
If you don't know what Web Services are, you probably don't need them. Web Services are a way (speaking generally here) for one web application to talk to another. You can formulate a request as an xml document and send that xml to a web service, which is listening on a specific URL and port. The Web Service can then perform some action based on this document, and respond back with an XML document. It's commonly used as a means for integration between applications.
If you're building a simple e-commerce site, which does not integrate with other live web products, then likely you don't need Web Services. Spring Web Services is simply an API/library to make reading/writing web services easy.