I am creating a Chrome extension which will send the URL of every page I visit to a remote database to be stored. I am thinking of creating a RESTful service using Jersey (java) but I am wondering if this will have any additional overhead in terms of the generating an unused response.
I am imagining that I will not require any sort of response back from the server after sending the URL (Kind of reminds me of UDP in a sense). Is a RESTful service what I want? (Since the server will not be sending any sort of data back to the user's browser)
You certainly can use a Jersey web service endpoint, but you could also use a simple servlet. I don't think Jersey is going to add much of an overhead to your incoming requests, but probably not much benefit either.
Since what you are building is a simple "log this" function and performance is a concern, it sounds like a simple servlet/JSP is likely to meet the need with no risk of unexpected overheads.
Related
I am new to RESTful webservice. Whatever I have read over the internet about RESTful webservice, I came to know that REST works similar to servlet + webservice.
Our traditional webservice looks like JSP-> Servlet -> Service -> DAO -> Database.
Will REST replace Servlet in this heirarchy?
My ultimate goal is that my web application should support mobile application and normal browser also. Is it good idea to use REST in that case. If not, in what situation we should use REST?
I hope my question is clear.
Please help me.
Thanks in advance.
There are many ways we can achieve Machine to Machine communication.
Web services also helps communicating between applications made in different platforms.
For example a .net GUI can call a java server side program for data.
REST is one of that kind, based on HTTP protocol.
SOAP web service is heavy weight (using lots of XML) where as REST is simple and you can expose any of your APIS simply using REST.
A services exposed as REST services can be invoked by a client using on of the HTTP verbs GET, POST, PUT, and DELETE with their meaning same as in HTTP.
RESTful Web Services expose the state of its resources.
An 'Employee' data can be queried and represented in any format (Json, XML ...) using REST.
Rest won't replace the Servlet in your hierarchy, actually the HTTP based REST methods are written on this servlets.
Please go through this URL : http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
Using REST is not related to browser experience on mobile or other devices. It totally depends on the client side technology used and your browser compatibility with those technologies.
Using REST is a good idea to access data at client side using simple AJAX calls.
REST means Representational State Transfer. It is a way of thinking about architecting network communication between client and server, with the focus being on transferring a resource from server to client and back again.
To understand the significance of this first consider a different architecture, Remote Procedure Call. This is where the client calls a function on the server as if the function existed on the client.
So you want to edit a photo that exists on the server. Your client is a photo editing app that uses RPC to achieve this. You want to blur the photo so your client calls the blur() function using RPC, and the server blurs the image and sends back the updated image. Then you want to rotate the image, so your client calls the rotate() function and the server rotates the image and sends the rotated image to your client.
You might have noticed two issues. Firstly, every time you carry out an action on the photo the server needs to do some work and send you back the updated image. This uses a lot of bandwidth.
Secondly what happens if tomorrow the server developers (who might be nothing to do with the client developers) decide that rotate() is the wrong function name, it should really be rotate_image(), and they update the server. Your client continues to call rotate() but this now fails because such a function doesn't exist on the client.
REST is an alternative way of thinking about client/server communication. Instead of telling the server to carry out an action on the resource (eg rotate the photo), why doesn't the client not just get a representation of the resource and carry out all the actions it wants to (blur, rotate etc) and then send the new state of the resource back to the server.
If you did it this way the protocol to communicate between client and server can be kept very simple and will require very few updates. All you need is functions for the client to get the resource and functions to put it back on the server. The client will have to know how to blur the image and rotate the image, but it doesn't need to know how to tell the server to do this, it just needs a way of telling the server to save the updated image.
This means that the developers of the client can work away implementing new features independently to the developers of the server. Very handy if the developers of the client are nothing to do with the server (the developers of Firefox have nothing to do with the New York Times website and vice versa)
HTTP is one such protocol that follows this architecture pattern and it allows the web to grow as it has. There are a small set of verbs (functions) in HTTP and they are concerned only with transferring a representation of the resource back and forth between client and server.
Using HTTP your photo client simply sends a GET message to the server to get the photo. The client can then do everything it wants to to the photo. When it is finished it sends the PUT message with the updated photo to the server.
Because there are not domain specific actions in the protocol (blur, rotate, resize) this protocol can also be used for any number of resources. HTTP doesn't care if the resource is a HTML document, a WAV file, a Javascript script, a PNG image. The client obviously cares because it needs to understand the resource it gets, and the server might care as well. But the protocol between the client and server doesn't need to care. The only thing HTTP knows is that there is a variable Content-Type in the HTTP header where the server can tell the client what type of resource this is.
This is powerful because it means you can update your client independently to updating your server without updating the transfer protocol. HTTP hasn't been updated in years. HTML on the other hand is updated constantly, and web servers and web browser are updated constantly (Chrome is on version 33). These updates can happen independently to each other because HTTP never (rarely) changes.
A web browser from 10 years ago can still communicate with a modern web server over HTTP to get a resource. The browser might not understand the resource, say it gets a WebM video that it can't understand, but it can still get this resource without the network communication failing.
Contrast that with the example of RPC above where the client server communication will break if the server changes rotate() to rotate_image(). Every single client will have to be updated with this new function or they will crash when trying to talk to the server.
So REST is a way of thinking about client server communication, it is an architecture design/pattern. HTTP is a protocol that works under this way of thinking that focuses on simply transferring state of a resource between server and client.
Now it is important to understand that historically a lot of people, including web developers, didn't get this. So you got things like developers putting verbs into resource names to try and simulate Remote Procedure Call over HTTP. Things like
GET http://www.mywebsite.com/image/blur_image
And they would hard code the URI /image/blur_image into their client and then try and make sure the guys developing the server never changed the URI blur_image. You get back to all problems of RPC. As soon as the server guys move the resource blur_image (which is not really a resource to start with) to /image/blur_my_image the client falls over because it has that hard coded as an action to perform, rather than simply getting /image and doing what ever it wants to it.
So there are lot of examples on the web of doing REST wrong. Anything that tightly couples client and server communication is doing REST wrong. Your client should be able to survive URIs changing, or Content-Types being updated, without falling over. It can complain it doesn't understand a resource (eg Netscape Navigator 2.0 complaining it has no idea what a HTML5 document is), but it should complain that a URI has changed. This is the discoverability aspect of REST, which I haven't gone into too much, but basically your client should be able to start at the root of the server http://www.mywebsite.com and if it understand the content types it should be able to continue on to the resource it wants. You should never need to hard code a URI into your client other than the root of the server.
I could write a book about this stuff (and many have), but I hope that serves as a good introduction about what REST actually is.
#javafan I just checked the mykong example you provided. Please note that that is not standard http servlet implementation, it is a Jersy way of implimentinmg rest. So when you map all your URIs goes through this servlet com.sun.jersey.spi.container.servlet.ServletContainer and you write classes with annotation #path etc the Jersy runtime environment will do the necessary processing for you like converting the input and output objects to necessary formats (json, xml etc) depending on your configuration. You can write a simple servlet and add methods in it with #path annotation in it and that will be invoked inturn when you make the corresponding request. but the doGet and doPost methods are standard servlet methods that processes GET and POST method by default. You can ad another methods to the same servlet and add more qualifiers to process your request.
#GET, #Produces("xml") etc.
I hope this helps.
I'm facing a performance issue with my web-service.
The context
I'm coding a game on Android that consumes a web service. It 's a multiplayer game so there are many connections done to the web service.
My Rest web service is provided by an Axis2 instance on a Tomcat server.
The problem
All is working fine, except that the amount of data is huge because of the verbosity of XML.
I tried to optimize the exchange by never resending a data that the client already have.
I use gzip compression.
I think that jSon is not a solution because, it will light the response message but not as I would.
So my questions, what should I do to maximum light the response size? What are the best practices?
Is it possible to send only a serialized object without using jSon or xml to avoid verbosity?
Thank you for all your reponses xD
I think that I have to send serialized objects in a custom format but Axis2 only deals with xml stuff (Jax-WS).
So I'll try another Rest server like Jersey which deals with custom format (Jax-RS).
What do you think about that?
I want to send an XML file to a Web Service.
The Web Service is a java application.
I know the endpoint of the Web Service.
Typically I know I have to create the request and send it as an http/https request.
What I want to know is what would I have to make to send the request - as in what development tool could I use e.g. Visual Web Developer (preffered as I am familiar with this) or Visual Studio? And what sends the request - e.g. another Web Service, a Website etc?
Where do I even begin with this?
Any comments are much appreciated.
Where do I even begin with this?
One purpose of a Webservice is loose coupling. So it depends on what you want to do. You can write a simple program in what ever language which constructs a request and sends it. You can write a Webservice on its own which uses the other Webservice to handle it's own requests.
You can handle this in a very simple or complex way. You only need to be able to generate a request (per xml) and send it.
I'm looking to add a web services interface to an existing server application. The set of services to expose is not known at compile time and can change over the runtime life of the server.
From a tech standpoint all the server/web services endpoints will be on Windows.
In our server app a user will have the option to register workflows as 'web services callable'. This will create the WSDL defining this particular workflow service.
For the calling endpoint I'm thinking of an HttpModule that accepts the inbound web service request, unpacks the request and converts the XML data types into our server applications "domain", calls the server and finally converts the server outputs back into XML for return down the http connection.
Does that make sense?
Critical comments welcomed.
In effect writing your own WS engine. Clearly doable, but quite a bit of work to get right from scratch. I guess if you find some open source implementation, then adapting it should be possible.
A rather dirtier alternative, but one I've seen applied in another context, is to go for a simgle WS interface
String call( String workkFlowName, String payload)
The payload and response are both Strings containing any XML. So the caller needs to undestand the schemas for those XMLs. From the client's perspective the amount of coding effort is not much different. Your coding effort would I think be significantly redcued.
an HttpModule that accepts the inbound
web service request, unpacks the
request and converts the XML data
types into our server applications
"domain", calls the server and finally
converts the server outputs back into
XML for return down the http
connection.
That is what all web service frameworks do (e.g. Metro, Axis). So I can't see your problem. What's your concern with this approach?
The downside for the client is that, as far as I understand it, availability of your services may change over time. So you should consider a way to inform the client if the service is available (other than getting a time out error because it is not there), e.g. WS-ResourceLifetime or UUDI.
I ended up creating a C# class that implements the IHttpHandler interface. The implementation serves up the WSDL of the services exposed from our app and accepts SOAP posts to invoke the services. In the end most of the work went on converting SOAP types to our types and vice versa.
I've been looking at http traffic analyzers which are browser addons that monitor and analyze all incoming and outgoing HTTP traffic between the browser and whatever web server you're connecting to.
The types of information available per request include:
* Request and response headers
* Sent and received cookies
* Querystring parameters
* POST parameters
* Response body
My question is whether it makes sense to use this to build a web service.
What I am interested in is using Windows SkyDrive - which offers 25GB of storage per user account - as a storage solution for my web app.
So what I am considering is using HTTP traffic analysis to figure out how to get my web app to mimic a browser interacting with my SkyDrive account.
Is this a bad solution? I have a feeling one of two things could happen quickly:
Microsoft figures out that these are automated requests and shuts down my SkyDrive account and deletes the data.
Microsoft changes the authentication front-end regularly, requiring me to repeatedly reprogram the portion of my service that interacts with SkyDrive.
Has anyone tried something like this and encountered difficulties? I would like to hear some feedback on whether this is likely to be worth the effort or not.
What you want to do is probably possible, technology wise. But is it allowed under the terms of service of SkyDrive? and what is the worst case scenario if they do change their protocols? Will you be trying to run a business off this data? Have you considered using something like Amazon's Simple Storage Service, which is designed to accommodate exactly what you want to do? Why waste your time reverse engineering the skydrive protocol?