I'm currently working on implementing the public API of our web application. The application is written in Java.
This is a financial application deployed on Tomcat. My users can manage their sales, customers, purchases, inventory, etc. It's a pretty huge application. The font-end is written in Java/GWT. The backend is written in Java s well. We use the GWT-RPC mechanism between.
What we want is to provide a way to access the financial data (read + write) via a public API. This way, developers will be able to better integrate their application (like a payroll application).
We don't use any framework. No Spring, grails, whatever. Also, no Hibernate, JPA, etc. It's a pretty old app, with lot of proprietary code for the ORM, XML-> javabean. authentication, etc. Cannot change all of that as the application is already in production and it just works that way.
The API infrastructure will be on a different sub-domain and on a different server.
The API should use Oauth to authenticate the users.
I looked into Grails, Play!Framework and Restlet to achieve my goals
Does anyone have some thought on them? Am I going in the wrong way with those frameworks? Is there another framework to look at?
Thank you all
I'd recommend following the example of Amazon and such and expose that API as web services, without regard for UI. Your have a further choice about SOAP versus REST. I think you'll find that REST will be simpler for your clients, because they only need to know about HTTP.
This doesn't mandate the use of any frameworks if you choose not to. The back end will work regardless of whether or not you use Spring, Hibernate, Grails, etc.
You'd have to rework the application you have to call the services if you wanted true reuse, but it might be worth it in the long run. Both your UI and clients would be using a common back end API that way.
I have some thoughts yes. Financial applications tend not to use OAuth. To be clear: nobody with vulnerable data uses OAuth. That includes privacy, medical and financial data.
What kinds of deployment environments do you expect to use this API. That might narrow it down, the standard answer if you have absolutely no idea who your client is, is still supposedly SOAP (since so many people know and accept the buzzword).
If you're going to expose read/write to a Java-based financial services application over the public internet, I would look at SOAP-based web services with JAX-WS as there is a pretty mature security spec in WSS and the API is relatively easy to use and may not require much in the way of changes to your existing app.
REST is perceived as easier in general but for this type of application you might find your target audience is more familiar with SOAP anyway. All depends who your target audience is and exactly what you're trying to achieve, but worth considering.
Related
First am not sure if this question fits here well. However couldn't think of a better place to get help. I've been tasked to list the Pros and Cons of each of these {JAX-RS, Playframework scala, MS Web Api}. I've done some research but couldn't conclude as I've not used all three to great extent. Have used playframework to create simple REST app. Have read the Web Api tutorials but have not implemented anything. Did research on JAX-RS but haven't implemented anything either. Also most of our developers are familiar with C# and introductory Java. I am more inclined towards playframework due to Scala,Akka,no server restart and scalability etc but not clear about the cons. One thing am sure is JAX-RS is standard Java EE and Web Api is standard MS stuff. Below are some of the app requirements:
Purely REST backend.
Proper authentication and authorization.
Online secure payment {Paypal etc}
Single front-end for both mobile and desktop
{angular/backbone/knockout..}
Allow users to subscribe as companies or part of companies.
Be able to connect to different databases without App restart.
Code maintenance and readability. Other members should be able to pickup without hassle.
Scalability
This is a partial answer because I worked only with playframwork 2.0 and JAX-RS.
Playframework is a MVC framework, you can use it to create some REST services but it's not focused on this kind of applications, so at least in version 2.0 it wasn't easy to add complex behavior like interceptors, etc. and you should manage authentication by yourself, I don't know if this has been improved in most recent versions of play framework.
JAX-RS is a specification to create REST services, there are several implementations like
Jersey, RESTeasy, Restlet between others. So JAX-RS implementations are built specifically to provide REST services in java. Most implementations have support to several authentications mechanism like OAuth, etc.
In my experience, JAX-RS is better to provide RESTful web services, and the code generated is in general more maintainable than the code generated in playframework, also playframework has a lot of things that maybe you don't need to use, but it will be loaded in memory when you start the server anyway. Akka it's a cool technology, but you can use it if you want it in any JAX-RS implementation.
If you want to build REST services using Scala, you could try Scalatra http://www.scalatra.org/
If you prefer java, take a look at http://dropwizard.io/, it's an embedded server that has Jersey (An implementation of JAX-RS) and a lot of cool things to provide RESTful web services, like metrics, etc, also it's easy to learn. If your team doesn't have an advanced java knowledge, this is a good option.
Playframework is great if you want an easy to learn MVC, specially for non java programmers but definitively it's not the right tool to build RESTful webservices based applications in my experience.
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
This is a very beginner question. I have tried to search for advice but am overwhelmed by the amount of information and would like some help with ideas on approaches to server design or what to search for!
What I would like to set up is a backend server that provides search capabilities and business logic and validation across some fairly basic data. It wont get too large.
I would then like to be able to plug in a website as a front end or a mobile app or a facebook app or even a desktop app..
My question is what is the best way for front ends to hook into the backend? I would like to have various user accounts with permission levels so authorisation would be important.
I generally only code as a hobby so whilst technically I have built a spring based website before the exact semantics of the client server relationship weren't clear to me. Now I want to separate the backend so that is is agnostic of how the data is displayed or entered completely and can run on a separate machine.
Thanks,
Rob
There is a ton on options. I had good expirience with apache CXF rest services (logic encapsulated in java beans, spring configuration) and pico web remoting ( more exotic,
but also rest service and plain java objects providing business logic)
if you ar already using spring, I would recommend to stick with CXF - it integtrates seamlesly ( and is spring configured itself )
I've been asked by a client to develop a server heavily based on web services and web interfaces (HTML + Ajax GUIs). Now before I start googling, I'd like to hear from you all, what do you recommend for such a task. My goals:
Work with Spring + Hibernate (This is a basic requirement). I know there is Spring-WS, but it seems a little bit complicate. More it doesn't seem to integrate with Eclipse or Netbeans web service generation functions.
Be very very simple, to the level that every newbie can get into that easily and even seasoned developers, that are not so sparkling with new technologies, can work with it.
Ideally I'd like it to be easily assisted by IDEs like Netbeans or Eclipse, or Both!
I'd like if it is possible to have the same application serve J2EE webpages and the services
REST or NOT?
I don't want to implement nothing by myself, but I want to rely on existing solutions. I mean, I've been thinking of using JSON-RPC, but I've seen around that it is poorly supported on many platforms, plus I'd have to write certain parts by myself. I'd like proven technologies that work.
And eventually I'd like it to make coffee for everybody... no okay I'm kidding about this :)
check apache CXF. it is pretty simple and supports spring
http://cxf.apache.org/
Regarding REST it depends on the type of service you are trying to implement.
If the information you are returning would fit well in a tree structure then a REST service will map it very well and clients can get the granularity they need.
If you can't really 'drill down' into your data then maybe REST does not fit.
I've been looking into JAX-RS lately because I really like the Java platform and a RESTful style of web development. I've read a lot about using JAX-RS for creating RESTful Web Services, but is it possible to use JAX-RS to create RESTful web sites? I guess more specifically, is it possible to use JAX-RS as a controller (to retrieve required data from the server) and then forward control to a view engine to render the appropriate HTML?
I've been googling around but haven't found any resources that show you how to do this.
Thanks for any insight/help.
I think you are having difficulty with your google searches because not many people are doing this. JAX-RS was designed for web services, so developers don't think of using it as a controller for web applications. However, there is no reason it wouldn't work.
Check out this blog post: JAX-RS as the one Java web framework to rule them all?
I think it's exactly the kind of thing you are looking for.
If you truly want to rely just only JAX-RS for your web framework, Jersey might be your best bet. Keep in mind the features you get from it are going to be bare minimum and you are obviously not going to get all the bells and whistles like what's provided by JSF, Wicket, etc.
If you know your web application is going to rely on Spring, perhaps you should consider using Spring MVC 3.0. It provides restful web services-alike and it gives you better features so that you don't need to implement most of them yourself. Granted, Spring MVC 3.0 is not an implementation of JAX-RS and based on what the Spring developer said, it seems like they will never make Spring MVC as an implementation of JAX-RS since they are already quite a few stable implementations out there. However, the syntax is pretty similar in my opinion, or at least I was able to understand them rather quickly even though I have been using Jersey for quite awhile.
dbyrne is right that almost no one is doing this. It's more conventional to use JAX-RS to dump information to JSON or XML. Then you fancy up the web browser with an RIA framework (e.g. Ext JS), which handles manipulating the DOM and injecting data as its fetched in JSON/XML form. This approach is powerful. You can write multiple, possibly non-browser clients for the service, all parsing the same JSON/XML. You can write "one-page" webapps, where all information exchange happens through AJAX after the initial pageload. I urge you to investigate and consider its strengths and weaknesses in the context of your particular problem.
Returning to your question: the answer is "sort of". This functionality is not directly provided by the JAX-RS spec (as of 1.1). However, it is in the JAX-RS reference implementation, Jersey, through the Viewable response object. See this blog post if you want to investigate further: http://blogs.oracle.com/sandoz/entry/mvcj. I want to point out that I have no experience with this side of Jersey. It has been pleasant to write XML/JSON-returning web services with Jersey, but I can't speak to this server-side HTML templating business.
Edit: dbyrne's edited his answer to include a blog post which points to the one mentioned above. I think we've both converged on approximately the same answer.