I'm trying to figure out wether I should use SOAP or REST for a specific project. I will explain what the project is or needs to do, and I hope some of you will give me useful information about why I should use one over the other.
The project I need to work on is totally web service based. Every frond end implementation needs to access webservices to get all the information it needs. But Beyond that, we also have an Indesign plugin that talks to these webservices to upload documents and check validations on the document etc.
So to make it short, I need to access the web services via front end web gui's and via an indesign plugin. The latter makes me wonder wether I should use REST or SOAP.
Thanks alot for reading this and posting you feedback.
I found this really great article on the advantages and disadvantages of SOAP vs REST: http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/
And my own humble opionion:
I don't like SOAP, I never did. It's been great at the time, but it just never felt "right". If you've ever tried to read one of these huge overloaded XML-documents and compared it to the REST output (which is JSON most of the time) you know what I mean. IMHO just feels "better".
One problem is that you have to document your REST API better, but that shouldn't be that big problem as long as it is not open to everyone.
Especially if you handle all your data with Webservices, I think you should go with the lighter and less bandwith consuming option: REST.
Also REST is the new and hip technology that everyone uses at the moment... ;)
About your indesign plugin: You should be able to include any library you want, so that shouldn't be a problem.
Related
At every moment in the world things change, said some guy.
We're sitting on a big fat REST API server which is becoming more and more of a burden to maintain because good Java developers are hard to find, expensive, development takes much more time, so we're slowly switching various application parts to Rails, which is... well, nevermind.
There are way too many APIs (and some are poorly documented) to just clone functionality by looking at the docs, so my idea is to find a way to log everything that's passing through this service for a while, in a machine-readable format we can later index, process and report, so we can gradually rewrite the code.
Is there a "clean" not so "hacky" way of doing this with Tomcat? Or should I go down the wireshark/reverse proxy way?
TIA!
You can create a payload logging filter and configure it in your web.xml. You can also use an output filter for the response. This and this should be helpful working examples.
My Company is going to start new project this year which need to archive web services on it way and I need to make decision on some technical things. After some research on web I thought that Qt and gsoap also can be candidate for the job we want to be done.
We were working long time with Java and C# based web service but now we need to solve two problems mentioned below:
Web service need to be extremaly fast
Easy adding service mwthods to it as we go
To be honest I think that we will not have much work in this side just several service methods to analyze and store data in database.
Thats why, as performance is very important for us we think that Qt + gSoap is option to go with.
It will be very nice to know what to use Qt/gSoap/C++ or Java/Jax-Ws taking in consideration two options listed above?
Thanks in advance
To preface I am new to web development. I am looking at creating a core set of RESTful web services around a valuable document library of sorts (initial CRUD abilities). In doing so I am theoretically creating a perfectly re-usable and scalable back-end to be used by unanticipated applications in the future.
My question centers around the best practice for doing this. My initial requirement has me also creating a unique front end. Would I make the front end and back end completely separate projects to enhance the re-usability. It would increase overhead.
Looking at using GWT, Restlet, and the Java EE technology stack if this influences the setup at all.
Most important is design a clean Java API - independent of REST, RMI, or whatever protocol you want to use. From a clean Java API, you can support any access method.
Unless you have a use case for these other access methods, don't build them now. You can build it when you need it.
The easiest interface to add initially is a web based interface where your web app runs in the same JVM as your core API. I'd do this if this works for your use case. Building a separate console application that accesses your core API via a REST (or whatever) protocol is a lot more work..
Martin Fowler wrote a very nice article about the basics of REST short time ago: Richardson Maturity Model. Found it very helpful to understand the principles of REST.
If you want to use REST based backend services, you should use the RestyGWT project which allows you you to use a GWT-RPC programing style to access your JSON based restful services.
The nice thing about using REST based JSON services over traditional GWT-RPC services is that those services can then be used by other clients or even in mashups more easily.
You may want to consider using GWT-RPC instead of REST if you know you're going to be using GWT for the frontend. More discussion here.
However, if you think you might want to eventually expose your data via a REST API, or use a different technology on the frontend, REST may be a better choice.
The gwt-rest project may also be helpful.
A colleague and I have written a GWT system using separate projects for front and back ends. It has been helpful to keep things quite clear about where the code is executing. But I'm not sure that I would bother separating things in a future system.
Also, given you're new to web development, I don't think you should be expecting to make a perfectly re-usable backend. You will learn lots of things as you go. I think that agile coders would recommend an iterative approach of (a) getting a small aspect working, and then (b) refactoring it to make it beautiful.
i'm building my webapp using the wicket java web framework. there is one page that i'm building right now contains 20+ external links, a lot of them are pointing to the wikipedia pages. i'm currently hardcoding the url for all these links in the html page.
i could definitely add these links by using the framework (wicket has a class for external link), but i really wonder, is there really a point to do so? all these links are external and they very likely won't change for a long long time. it seems to me if i add them using the framework, it simply just increase the amount of code and it's just a matter of hardcoding java code vs hardcoding html. i really can't think of a reason to do them via the java side.
i'm just a newbie programmer who is trying to learn how to use web framework, so i wonder am i missing anything here? thanks for your help!
When in doubt, go the simple route. You can always refactor and add complexity later if it turns out you need to be more dynamic.
In my opinion, all of the text and links in a web application should be externalized. It's a minimal amount of effort to store this information in a properties file (or content management system for larger applications). This will make it easier to maintain and internationalize your application in the future.
Hope it helps!
--Neal
Remember KISS and YAGNI. If you think the links don't change, wait with programming until you need the flexibility. Flexibility comes always at a price!
On my current project, we've been using Struts 1 for the last few years, and ... ahem ... Struts is showing its age. We're slowly migrating our front-end code to an Ajax client that consumes XML from the servers. I'm wondering if any of you have migrated a legacy Struts application to a different framework, and what challenges you faced in doing so.
Sure. Moving from Struts to an AJAX framework is a very liberating experience. (Though we used JSON rather than XML. Much easier to parse.) However, you need to be aware that it's effectively a full rewrite of your application.
Instead of the classic Database/JSP/Actions scheme for MVC, you'll find yourself moving to a Servlet/Javascript scheme whereby the model is represented by HTTP GET requests, actions are represented by POST/PUT/DELETE requests, and the view is rendered on the fly by the web browser. This leads to interesting challenges in each area:
Server Side - On the server side you will need to develop a standard for exposing data to the client. The simplest and easiest method is to adopt a REST methodology that best matches your data's hierarchy. This is fairly simple to implement with servlets, but Sun also has developed a Java 1.6 scheme using attributes that looks pretty cool.
Another aspect of the server side is to choose a transmission protocol. I know you mentioned XML already, but you might want to reconsider. XML parsers vary greatly between browsers. One browser might make the document root the first child, another one might add a special content object, and they all parse whitespace differently. Even worse, the normalize() function doesn't seem to be correctly implemented by the major browsers. Which means that XML parsing is liable to be full of hacks.
JSON is much easier to parse and more consistent in its results. Javascript and Actionscript (Flash) can both translate JSON directly to objects. This makes accessing the data a simple matter of x.y or x[y]. There are also plenty of APIs to handle JSON in every language imaginable. Because it's so easy to parse, it's almost supported BETTER than XML!
Client Side - The first issue you're going to run into is the fact that no one understands how to write Javascript. ESPECIALLY those who think they do. If you have any books on Javascript, throw them out the window NOW. There are practically no good books on the language as they all follow the same "hacking" pattern without really diving into what they are doing.
From the lowest level, your team is going to need remedial training on Javascript development. Start with the Javascript Client Guide. It's the de facto source of information on the language. The next stop is Douglas Crockford's videos on Javascript. I don't agree with everything he has to say, but he's one of the few experts on the language.
Once you've got that down, consider what frameworks, if any, you want to use. Generally speaking, I dislike stuff like Prototype and Mootools. They tend to take a simple problem and make it worse. None the less, you can feel free to evaluate these tools and decide if they'll work for you.
If you absolutely feel that you cannot live without a framework because your team is too inexperienced, then GWT might fit the bill. GWT allows you to quickly write DHTML web apps in Java code, then compile them to Javascript. The PROBLEM is that you're giving up massive amounts of flexibility by doing this. The Javascript language is far more powerful than GWT exposes. However, GWT does let Java developers get up to speed faster. So pick your battles.
Those are the key areas I can think of. I can say that you'll heave a sigh of relief once you get struts out of your application. It can be a bit of a beast. Especially if you've had inexperienced developers working on your Struts model. :-)
Any questions?
Edit 1: I forgot to add that your team should study the W3C specs religiously. These are the APIs available to you in modern browsers. If you catch anyone using the DOM 0 APIs (e.g. document.forms['myform'].blah.value instead of document.getElementById("blah").value) force them to transcribe the entire DOM 1 specification until they understand it top to bottom.
Edit 2: Another key issue to consider is how to document your fancy new AJAX application. REST style interfaces lend themselves well to being documented in a Wiki. What I did was a had a top level page that listed each of the services and a description. By clicking on the service path, you would be taken to a document with detailed information on each of the sub-paths. In theory, this scheme can document as deep as you need the tree to go.
If you go with JSON, you will need to develop a scheme to document the objects. I just listed out the possible properties in the Wiki as documentation. That works well for simple object trees, but can get complex with larger, more sophisticated objects. You can consider supplementing with something like IDL or WebIDL in that case. (Can't be much worse than XML DTDs and Schemas. ;-))
The DHTML code is a bit more classical in its documentation. You can use a tool like JSDoc to create JavaDoc-style documentation. There's just one caveat. Javascript code does not lend itself well to being documented in-code. If for no other reason that the fact that it bloats the download. However, you may find yourself regularly writing code that operates as a cohesive object, but is not coded behind the scenes as such an object. Thus the best solution is to create JSDoc skeleton files that represent and document the Javascript objects.
If you're using GWT, documentation should be a no-brainer.
Check out the Stripes Framework. If you are familiar with struts then stripes will make sense to you, but it's so much better. They have a Stripes vs Struts section on their website. You could check that out and see if it interests you. It allows you to work with any ajax framework you want, and I don't think it would take long to migrate from struts to stripes.