I am new to Java GUI, I have knowledge of core Java.
I have to call a REST client from my NetBeans project, give values to it, and receive its output in the same project.
Please point me to some helpful resources.
This tutorial covers the basics using Twitter's REST api which should be stable enough for you to be confident that any errors you see are in your implementation and not the API.
"In this tutorial, you create a NetBeans platform application that consumes the Twitter What Are You Doing service, displaying a list of your Twitter friends' status messages. First you create the platform application. You select the libraries needed in the application. Then you create a NetBeans module. Finally, you add a RESTful client and some basic display elements to the module. The client uses OAuth authorization."
https://netbeans.org/kb/72/websvc/jersey-rcp-client.html
You could try looking at the Oracle documentation on JAX-RS clients, which is how you can access REST resources using Java.
http://docs.oracle.com/javaee/7/tutorial/doc/jaxrs-client.htm
In addition, client libraries like RestEasy and Jersey can help make your life even easier.
When dealing with RESTful webservices, you'll also want to know how the request bodies map to your Java objects. Are you using XML, JSON, a combination? It will help to know that as well so that you know if you need an XML mapping framework or a JSON mapping framework. You can just parse the strings, but depending on how complex it is, that might get really messy!
Related
I've been googling for some time on how to use Swagger in Java application but I did not find any helpful resources so I'm asking here. I know it's quite general question but I need to find some kind of starting point to be able to get next steps.
So, I have JavaEE application which gets some JSON through http, parses it and does sth with this data. I was given a totally new API specification made in Swagger (1.2 to be exact). The problem is that I do not know how to stick it together with my application.
Should I load JSON file with spec to my application and then do sth with it?
Should I use swagger-codegen to generate Java client code and then use it someway in my application?
And what is the 3rd step? How to invoke http requests with this Swagger api?
In general, the question is about integrating Swagger json api to Java application. I would be very grateful for any hints or links to tutorial or sth:)
Given that you've the API specification in Swagger (1.2), you can use Swagger Codegen to generate the Java API client and use it in your JavaEE application.
Here is one way to generate the Java API client online without installing swagger-codegen locally:
https://github.com/swagger-api/swagger-codegen#online-generators
Hi I am working REST Services and I just want to know how can I provide the web descriptor for REST Services. It will be great if their is some API that can directly produce the WSDL for REST Service.
I am using Spring STS for development is their anything inbuilt in Spring STS.
I have few more questions for the same:
Is it feasible to provide the descriptor for REST Service.
Providing the descriptor is not the violation of REST or HATEOS architecture style.
What are the different ways to achieve this.
REST services shouldn't use WSDLs. WSDLs are used for SOAP Web services, not for the REST design style.
Instead of using WSDLs, REST APIs should be discoverable.
Possible duplicate of this Stackoverflow question.
Though it's possible to generate some sort of WSDL if you use WSDL 2.0, people don't seem to generally describe REST services with WSDLs. This is because REST services are usually HTTP requests with GET/PUT/POST/etc methods.
At best, people can generate something called a WADL, but generating WADLs hasn't really taken off in the general community.
There's no de facto standard for describing REST APIs. If you need to automate it, I recommend looking up how to generate WADLs.
There are also other solutions/alternatives out there used to document and describe REST APIs. It all depends on what your actual requirements are.
Some other good Stackoverflow questions to explore:
What is the reason for using WADL?
Why the slow WADL uptake?
Provided a WSDL I create a dynamic web service client. What I want is to expose the methods and the types of the parameters those methods have and test the code from a webpage. Bare in mind that the client is dynamic, so what I have to build must me able to work with different WSDLs.
What I want to do is what the Eclipse web service explorer does for testing a web service client from the provided user interface. How does it find the methods and the parameters? Does it parse the WSDL? I've searched for the source code, but I couldn't find anything relevant. I don't even know where to begin.
What I want is suggestions and some guidance of what I have to build, what is already provided out there (that I'm not aware obviously) and a place to begin. I'm not asking for code.
Essentially creating a generic web services client would involve the following:
Analyse the WSDL for service definitions i.e. the method names and their definitions. Remember your WSDL defines your service.
Analyse any XSD (embedded or linked) to retrieve the datatypes of the parameters etc.
As a suggestion why not look at the SOAP UI project which is really great as a generic web service test client. As it is open source you might be able to learn how they do it. Go have a look at the project here
Also go look at the Apache CXF framework. This framework will allow you to easily create a webservice client. See this tutorial for more information: how to create a client in CXF. CXF is also usable via javascript so it might be what you are looking for see this link
I would suggest that you try leveraging these tools before you try to invent one yourself as parsing WSDL's and XSD while NOT difficult to parse it going to take a substantial programming effort. CXF already has this covered for you if I read your question right.
I like Play 2.0 much (especially Scala API). But it lacks SOAP completely. Is there some not mindblowing way to provide SOAP WS (wsdl based) from Play 2.0?
Say, I'd want it to be accessible from some URL (e.g. /soap), preserving other pages to be HTML. Please, help, I have no clue (I'm java newb, and zillions of abbreviations for frameworks and libs make me confused).
PS To prevent possible unproductive treatments: I'm a java newb but not a newcomer programmer, so I know how SOAP, HTTP and other stuff are meant to work at protocol level.
I ran into the same problem - Apache CXF and Axis2 depend on the Servlet API, which the Play Framework doesn't have.
I created a custom transport plugin for Apache CXF which connects to Play's Controller API.
There is a tutorial about setting it all up in an empty project: http://www.imind.eu/web/2013/11/07/developing-soap-services-using-play-framework-2-2-x/
The plugin's source (and a sample Play application) is here: https://github.com/imindeu/play-cxf
If you trying to create a web service API for existing business logic that will be part of your Play service, then you should probably look using existing Java libraries that can do the SOAP magic for you (e.g. Axis2). Scala can use existing Java libraries without any problem.
However, most people would strongly recommend you look at a REST service rather than a SOAP service, if this is an option. Have a look at Play Mini to see how this is done.
UPDATE:
Ah, this may help you: https://github.com/mandubian/scala-xmlsoap-ersatz
Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.