It's not a very concrete question. I created a simple project with a help of this tutorial, it's really fine. All the GWT code samples related to JSON I saw so far seem to work with a JSON (or immitate this work with some mock-up JSON), that is retrieved and processed in GWT. I'm a newbie in GWT, and I wonder, what are the cases of interacting with services that return JSON (services are mentioned in the same tutorial) and what are the pros and cons of such interaction.
I thought about two options (well, service is an overloaded term):
everything that is mentioned in these JSON GWT tutorials is about the third-party services, like GData and Yahoo! Web Services mentioned here, which would make sense, cause it's about retrieving some data and processing in the app,
and the second option is about services, that are created within the confines of a project (and, if there are some cases, and definitely there are some, my question is about them).
It's probably can't be fully explained in the answer, so a link (or a few) would be appreciated. Thanks in advance.
Your question is really quite generic. But here are some pointers:
JSON is just a data interchange format similar to XML or Protocol Buffers or some other proprietary format.
They are necessary in modern web applications because the UI is entirely controlled by the javascript code running in the browser.
However the data that a web application presents to the user usually resides on the backend. In order to get the data from the backend to the frontend you have to use some data interchange format like JSON or XML.
The advantage of JSON is, that is fairly efficient compared to XML and well accepted.
As you mentioned there are third party services that rely on JSON. These are very useful when you want to include the services in your applications.
The biggest advantage of applying this service oriented approach to your own project is that you decouple your components (frontend and backend). By doing this you achieve following things:
Make your services available to other (web-)applications and users because your service exposes a specific API/data exchange format that they can use.
Easily replace or add another frontend (for example create a desktop application in addition to your GWT application) that can work with your data (display or modify).
Related
I am developing an Android application with my friend. I am currently responsible for the backend while she is working on the Android part. The backend is developed in Java using Lambda functions running in AWS Amazon Cloud‎. The frontend and the backend are totally decoupled (Lambda functions are exposed via REST APIs) except for the POJOs used on both sides. POJOs are serialized by the application into JSON when calling an API and deserialized again into POJOs (very same ones) by the backend when handling API requests.
We want to keep POJOs on both sides exactly the same for obvious reasons but we are wondering what the proper way to do it is. We see the following two options:
1) Simply copy code on both sides. This has the disadvantage of changing common code independently which, sooner or later, will lead to a misallignment.
2) Move POJOs out to a separate library and include it as a dependency on both sides. This seems like a more proper way to solve this issue but how do we ensure that both me and my friend know that a POJO has been changed? Let's say I remove one field from a POJO and create a new version of the shared library. I push changes to our repository and then... tell my friend that I made some changes so she should pull them, build the new version and include it in her project?
Is there a different (better) way to address this issue? Currently the backend is built with Maven but I can switch to Gradle if this would help automate things and make our code consistent (Android Studio forces Gradle builds).
I found similar questions of other people but they were either a bit different or remained unanswered:
Sharing POJOs between Android project and java backend project
Sharing one java library between Android and Java backend (gradle)
Sharing code between Java backend and Android app
There are certainly lots of other ways of doing this and better or not; I will leave that to you to consider.
But before going to sharing the POJOs, I ask you to take a step backwards and take a look at your architecture. You have essentially got:
a Java Backend with REST APIs, supporting JSON payload
an Android Application, capable of making REST calls and deserialising the JSON payloads.
If you note, above, the tech stack does not involve POJO on any level.
You see what I mean? POJO is an implementation detail for you and it is not wise to share it among your components.
How about looking into the future where you add more components to your architecture, say:
iOS application
Kotlin support for Android application
Will your inclination to share POJO code still be intact? Perhaps not.
From what I see, you should design and develop for a REST backend and a REST capable client. Thats all. That should be the bottomline.
So with that, coming back to your requirements of sharing the updates between the backend and the client, you can share the JSON schema between the two, instead of sharing the POJOs. And thereafter, employ an automated system (say, a simple script) to generate POJOs in the backend and the client.
This approach can have certain benefits. For instance:
You will be able to share updates now and in the future, as per your requirements.
This makes your modularity (or decoupling) better too because the backend and the client is not bound by the requirements to use POJOs. For instance, you can use Data class if you decide to use Kotlin in your client.
You can use versioned schema for future, for the times where the client cannot keep up with the backend, or the backend needs to update independently.
and more
Adding to the answer above, I would take advantage of the fact that both languages use Java compilers and apis. Whether the front end uses Java or Kotlin, you can call any of these api libraries directly from your code.
One api in particular, Json-B, provides methods for transforming your Java (or Kotlin) objects into Json for transport, then transforming the Json response back into Java/ Kotlin on the other end.
One caveat: I recently heard that at least parts of the javax.* package were scheduled for deprecation. They should work on Java 14 or lower, but if you are planning on updating in the future, this is something that you will want to consider.
For Java versions 9 or newer, you should also read this first. It will save you some time.
EDIT: Json-B is, in fact, disabled by default in newer Java versions (the package is included but 'hidden'), but the last article linked in the paragraph above talks about acceptable workarounds. IMO it is still the preferred option for working with Json in Java.
I've been reading about Jodd(java) framework and it looks interesting to me. But I see that it seems to be jsp/servlet based. Can you develop strictly html/html5 dynamic website without jsps with it?
Absolutely. As you can see, in Jodd Madvoc you have this concept of Result : each (java) action returns it. Results are the one that defines how you are going to render the page. By default, there are JSP results, as this is a standard, right; but nothing stops you to simply have a i.e. Freemarker result or to use any other template engine. People are doing this often. Moreover, Results are made to be configured. See: http://jodd.org/doc/madvoc/results.html
Result does not need only to return HTML content. There is a JsonResult for example, or RawResult that can return a JSON or any string.
If you want REST-ish interface that only results with JSONs, you can do that as well, checkout: http://jodd.org/doc/madvoc/rest.html
Madvoc should be configurable enough to fit your needs. Just don't think of it as a 'solution-in-a-box', but a real framework, that you need to dig just a little, but you will find what you need :)
You can develop strictly html/html5 dynamic Websites without JSPs for sure, there are many ways to do it, but in my personal opinion, I believe that you can use AngularJS for your front-end development (HTML5/CSS3). This framework will allow you to implement all your client side without minor issues. It is based on HTML5, so no JSP files will be required. If you are used to MVC or MVVM, well this framework will allow you to work with any of these two approaches.
Dynamic Web Application? Need to show data from a database or store records? No problem, Angular supports AJAX calls to REST Web Services which you can implement with the programming language you feel more comfortable. If it is Java, then you can go for some REST Web Services using Jersey.
Hope this information is useful for you.
Happy coding.
REST webservices imply the server-side is stateless (for the most part) and urls correspond to resources and HTTP GET/POST/DELETE/PUT methods correspond to operations on those resources.
I am planning to work on a JSON services layer that is dependent on server-side state, having urls that correspond to resources and having urls like /add /update /delete corresponding to different operations and all of those urls using HTTP POST.
What is the right terminology for this? Should this be called JSON
web services? Is there any specific term for this?
It looks like Jersey+JAX-RS would be very useful for this purpose. Is it ok?
Would it make sense to use Struts for this kind of application?
JSON is a file format which your rest service may (or may not) use to send its answers. If you use this format to communicate with your webservice, you cann say that your service is a JSON web service.
Indeed, Jersey is a good JAX-RS implementation. However it is not the only one.
If you need a webapp to interact with the webservice you can use Struts. However, you can use any other tool (included some more recent technology, struts is really old) for the front-end of your system.
Well, it's not REST. However trying to defeat that tide of general misunderstanding just isn't going to happen.
What you are describing is actually what most of the world views as REST and therefor should be mostly OK with just calling it as such.
In the presence of a true Restifarian, you will get some push-back because they will be correct - however, there isn't really much need to add a tremendous amount of confusion to your daily life as the distinctions (and the MASSIVE benefits they afford...) are largely lost on anyone you work with.
(1) is accurate enough, or simply rest. (2) is redundant but it is a good framework for the technology. (3) I would say no, but noticing when this question was asked, I'm sure you already decided.
I've bounced around Java and C# the last several years but now want to get up to speed with Web Services (RESTful). I used to be a master of J2EE circa 2003, but have since got side tracked into all kinds of stuff. I've worked through a couple of NetBeans tutorials (my IDE of choice) but they don't seem to expose the nitty gritty. I enjoy seeing how things exactly work, building an app from the byte array up.
Although I've touched a couple of frameworks, I've most enjoyed working with Java EE proper to understand the base case before the sugar of Spring/Hibernate is added.
Does that make sense? I am looking for a book or tutorial that really builds up your knowledge piece by piece so that you understand everything, not some Rails-like toolkit for rapid development.
Thanks-in-advance,
Guido
I'd start by doing a review of HTTP, since in practice this is a fundamental building block of REST web services, and it gets you into the right mindset for what comes next.
Next, think about how you'd structure the URIs for various resources. Martin Fowler wrote a good article on this topic. Various java frameworks for creating web services try to make it easier for you to map requests to specific methods, and even to map parts of requests (including path elements, query parameters, and the entire request body) straight into your object model. But all of this just help with the identification and manipulation of resources through URIs.
Next, if your resources are related, then think about hypermedia controls. You're probably used to putting <a href=""> links in web pages, and you certainly wouldn't want people to hardcode or bookmark every single URL in your website. How does the same idea extend to web services?
Next, think about actually moving data between client and server. JSON or XML? URI element or query parameter? Again, lots of java frameworks exist just to make this easier -- for example, Jackson and Gson for REST, JAXB for XML, etc. -- but the problem of dealing with HTTP-based requests and responses is very similar to the one that your average servlet container solved years ago.
Finally, consider security. For example, username/password or OAuth? HTTP or HTTPS?
There are lots of other details, but these topics should keep you busy for a while.
Have you checked out Jersey yet? This is the Java reference implementation of JAX-RS. There is a great community around this project, and the main author is available via mailing lists and forums and has personally answered questions of mine for some gnarly situations I ran into. The jersey site has a lot of great links to get you started from a variety of angles, depending on what you're interested in learning.
RestifyDayTrader has very good details of how to build a RESTFul service.
Java implementation can be found at Restified Trader
Java Web Services is a good read on learning Web Services.
I have a small project where I would like to generate dynamic data entry forms with a little bit of logic behind them.
A simple use case might be
a Football resulting form, so you have a button for a goalscorer, and when clicked the user will be prompted for a player. The form will then send a message (probably to a webservice, but maybe a JMS queue) with the event data. eg Barcelona, Goal, Henry.
Then I want to create a similar form for tennis...
My idea was that I would create a webservice, where you define business logic. (events, components, actions you take etc.) Initially I thought I would send the sport definition from the webservice in xml. Then write an app to parse the xml and dynamically create the data entry screen.
I was initially thinking of writing a webservice and returning a xml data. (which will look awful) the rendering technology could then be flex/ flash and be a thin client.
Then I thought it would just as easy to create the forms as a java app using the swing application framework and that was the way to go.
Then I thought, well, rather than write a xml schema to describe the java forms, can I just serialise a java class and send that across the wire.
Once on that path, I am now wondering if should just a java framework, and the dynamic forms become class that are called by reflection.
I would love feedback on the above approaches, and how people on stackoverflow would solve this problem.
thanks
David.
I would avoid serialisation because it is a bit fragile, difficult to do safely and difficult to diagnose.
You say it's a small project, so does the metadata really have to pass from client to server? Would you not be much better off very simply writing the metadata (really code) as Java code?
(FWIW, my first commercial Java project was creating forms dynamically from a database specification (with regular additions). Previous to that I working with C++ running an interpreter for training systems. In both cases I would now (and for the last decade), have written them as Java. Don't be put off by people mumbling disapprovingly about "hardcoded".)
I would consider XForms as well. It allows you to define both the data model and the UI as XML, and all you need to render it on the client side is a web browser. I assume the event would be submitted to a remote server, which makes the web browser as a natural choice.
This would enable you to generate the UI on the server based on what kind of sport event the user wants to report about, so you can easily add new forms, fix bugs, etc. without ever having to update the client software.
By the way, I don't understand your concerns about using XML. In my opinion it's a viable option for your use case.