Is there any open source CMS in a java/xml platform which supports REST based apis ?
Basically i like to deploy a CMS as well a widget like application who can communicate each other via REST? Have tried openCms and couple of others too, but couldn't figure out a proper interface either via http or rest?
Drupal allows you to do that using the Services project at http://drupal.org/project/services
It provides a REST based interface for CRUD access to its content and some other services.
Take a look at Hippo CMS; it's open source, Java based and offers a JCR based content repository with REST capabilities.
I've never used it, however, https://getdirectus.com/ looks promising. I like the fact that it's built to be headless, meaning it's core function is to be a CMS with RESTful API, as opposed to the API being a secondary feature.
Related
I just develop a tool with my classmates and we want to use Vue.js as Web interface.
For Description what we programmed. We developed a Java EE web application in Eclipse. We use Tomcat 7 as web server. I search a long time and i found nothing.
Vue.js is a javascript front-end framework. There is nothing to stop you from using that with a middle-layer/back-end technology like Java EE.
In your HTML pages(or JSP) just include the Vue.js file as mentioned in the documentation, and other .js files that you create as part of your vue.js frontend application.
The library can then interface with any HTTP-based backend methods that you expose (using Servlets, Controllers, etc.) depending on how your Java EE project is structured and what frameworks it uses.
While investigating the same question, I found this good blog that has a git repository too
https://blog.codecentric.de/en/2018/04/spring-boot-vuejs/
From a glance it looks like a read solid implementation, however it has some sticky setup i haven't come across before.
It dose however seem like a professional and scalable solution i will definitely
give a try.
https://github.com/jonashackt/spring-boot-vuejs
Thankyou 04/24/18 by Jonas Hecht
For sure you can.
Your java application, which is your "backend", has to expose its functionalities as Web services (REST Json WS should be the easiest for what you are trying to do).
To expose your services as Web services, you need to find the easiest framework fitting your need. You will probably need to dive into Maven if you haven't yet, because these frameworks tend to have tons of dependencies.
Your Vue.js interface will make calls to the backend via HTTP requests each time necessary (get a resource, update a resource, ...).
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!
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
As per my knowledge api and web services are used to fetch data from other websites.
So what's difference between them ?
Any Help!
EDIT
Can somebody please explain it with proper example ?
What is twitter and facebook api ? Can we say it's just a function or webservices to access their data.
A web service is just an API in HTTP clothing.
A web service is something delivered over the Internet for direct use by another computer (rather than a human).
An API is an Application Programming Interface. A website application might expose an API thorugh a web service. However, desktop applications like Excel or Word have APIs which have nothing to do with the web (they have VBA and COM based APIs).
Simlarly, a server application (eg. Joomla) might have a PHP based API that is used from withinthe server - ie. no web service necessarily involved.
All web services are APIs, but not all APIs are web services. One is a subset of the other.
Web Service is an API wrapped in HTTP.
All Web Services are API but APIs are not Web Services.
Web Service might not perform all the operations that an API would perform.
A Web Service needs a network while an API doesn't need a network for its operation.
An API doesn't need to be web based.
Web Services may also may not perform all of the operations one would expect from a full API.
API (application programming interface) is a list of methods and classes exposed by a programmer to use by other programmers, so eg if you use Twitter or Facebook API in your programs, you can make it cooperate with Twitter and Facebook, and do many useful things. :-)
There are many ways of exposing APIs (JAR files or RMI in Java, .net Assemblies, COM objects, DLL and .H files in C/C++, JSON over HTTP, XML over HTTP, many home-made methods).
Web Services are just yet another way of exposing API, in this case the actual execution of the exposed methods is done not on your computer, but on some other computer on the Internet (on the Web - hence name "WebServices").
A web service can be thought of as a type of API. But for the moment, you should forget that, and just concentrate on learning what an API actually is; a precise definition of methods for interacting with a piece of software. Sometimes, this involved sending data over a network, but usually we're talking about functions that may be called from a program.
For example, there's a function called FileUtils.rm in Ruby. This is the API; when you're calling the function from a Ruby script, it always looks the same. Then there's the implementation of the API; that's the code that actually removes the file - it might look completely different in every implementation of Ruby, but you (normally) don't care about that, since you're only dealing with the Ruby API.
Webservices available over internet.you can get information without actually having the classes or know how it works using http and soap protocols.
API is a kind of library (set of classes), you can use the functions available in that to perform some action in your application.
Check out the wikipedia entry on web API's at http://en.wikipedia.org/wiki/Api#Web_APIs.
It's well written, though pretty much agrees with what the others here say.
APIs exposed over web are Webservices
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.