Jersey restful web service on grizzly server, client javascript - java

i'm new with web service programming and i want to create,using netbeans 6, a restful web service using Jersey over a Grizzly server and then a client javascript in order to use this web service through a browser. So i started learning more on restful web service and i read a lot of guide over the web, then i started learning more on grizzly and jersey by reading jersey user's guide http://jersey.java.net/nonav/documentation/latest/index.html. I succesfully follow the tutorial to create the helloword example resource. So i created all the resources needed for the job and tested successfully with the browser...but i'm still confused: in particular i want know how i can create a static homepage which can be used by the users to select what is the desired resource. Can you give me some tutorial or example?? Thanks to all!
(Moreover i want to learn more on grizzly server and creating jersey restful web service, can someone give me a useful guide or book??)

So, the key to understanding RESTful web services is to understand the HTTP protocol more thoroughly. That's what makes it easier than (and often preferable to) RPC style services epitomized by SOAP. When you pull down a static web page, for example, you can think of it as a limited "web service" which serves only GET requests. In order to make a static web page which "selects resources," you would only need to provide URLs to the resources in question, as long as they're accessed via GET, because that's the same HTTP method used for retrieving web pages (and therefore is the default method for web browsers). If you want to access other types of resources, such as sending POST requests, you can use a form; other than that (with PUT, DELETE, HEAD, OPTIONS, etc.) you'll want to use Javascript or a more programmatic API for accessing the HTTP resources.
There are many good books in this space, and I've found these particularly useful:
RESTful Web Services
RESTful Web Services Cookbook
RESTful Java with Jax-RS
SOA With REST
The first two approach REST in theory and practice; they are more about the concepts than specific technology. The third addresses the Java standard for RESTful services as defined in JSR 311, of which Jersey is the reference implementation.
The last is more of an "enterprisey" book, but it's been useful to me from the approach of designing a system of web services, as opposed to one-off service resources.

Regarding Grizzly you can take a look at Grizzly User's Guide, specifically Http Server framework chapter. If you have more questions don't hesitate to ask on Grizzly mailing lists.

Related

RESTful webservices with Struts 2

We are evaluating one design for educational activity. We would like to create complete backend (which handles business logic) in form of RESTful web services.
These services can be used by various apps. Is it good idea to call these web services from Struts 2 framework? I read couple of docs, and people discourage it.
We would love to go with Struts 2 as team is quite strong on it. But if its bad approach, we may consider for other options.
If you want to leverage development on presentation layer between client-side and server-side (this is where Struts2) then you can utilize web services using a web services client API. At this point these web services can be used as data resources.
If you want to stay only on client-side then you don't need any server-side framework for the frontend development.
Note that The introduction to Struts2 and RESTful applications you have posted in comment introduces an alternative way instead of web services for creating backend in a form of RESTful API using Struts2 framework.
Using Struts2 for the REST instead of web services could be a solution for RAD (Rapid Application Development). Because web services are very complicated technology that used in upper high level architectures and using some alternative resource APIs might be cost effective.

How to prove Restful Web service is a web service? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
Yesterday I had an interview and I faced an interesting question where I got stuck.
The Question "How can you say Restful web service is a web service?". I was trying to explain all the possible ways to prove. But all the answers were blocked by the question "Servlets can do the same. So Servlets are restful web service?"
Can anyone share your thoughts?
To answer your question, lets ask first what is a web service?
In purely abstract terms,
A web service is a method of communication between two electronic
devices over the World Wide Web. (Wikipedia)
Now the accepted industry norm for the two devices to communicate over the internet is using XML messages (which makes it inter-operable)
This brings us to different type of web services, mainly divided into SOAP and RESTful.
A SOAP web services use the XML (which conforms the a specific protocol or xml schema which in other words referred as WSDL ). So a SOAP web servies puts certain rules/regulation on the way the messages are exchanged between the web services and their clients. The messages can be exchanged using any convenient protocol apart from HTTP.
Now in a RESTful scenario, you still exchange messages (xml/json etc) BUT there are no new additional specifications (I know WADL but its invented more for providing tooling support RESTful and has nothing to do the RESTful web services per se)
In RESTful, there are no new protocol definition (for exchanging messages). It uses already established norms of HTTP protocol which are passing parameters in URL as path elements and the HTTP methods to send data (namely GET/POST/PUT/DELETE).
Now coming on to your question of whether Servlets are restful web service are not, lets see what Servlets do
Accept the GET/POST request
Return an HTML (well generally) (which essentially is XML)
Now if a servlet is written in such a way, that it can be invoked by following URL
http://www.myrestwebservices/services/getstockquote/GOOG
This servlet
is mapped to the URL pattern /services/getstockquote
gets GOOG as input data in URL path, which it can parse, query some system to get the latest stock quote of Google.
Return the data as text/xml to the clients
Isn't this servlet satisfying the following basic requirements of a RESTful scenario ?
Use HTTP methods explicitly
Be stateless.
Expose directory structure-like URIs.
Transfer XML, JavaScript Object Notation (JSON), (text essentially)
So technically speaking, yes a Servlet is a RESTful web services, but that may not be enough for generic business requirement of a web services per se. So for a full blown RESTful web servies, we need a servlet (nevertheless) written specifically to address those basic business requirements.
Well you can possible design RESTful webservices with Servlet.
The Servlet helps you create HTTP response for a HTTP request. RESTful webservices seats on top of HTTP protocol so you can make a REST service with Servlet.
Any code (with any language etc) that is based on HTTP can be a restful web service as long as it conforms to the requirements of REST...
See: http://en.wikipedia.org/wiki/Representational_state_transfer
Everything is a Resource
All resources expose a standard interface GET, POST, PUT, DELETE
REST services are idempotent
Resources may link to other resources
Multiple representations
Stateless communication
See this post for details on the above
Your approach for such questions should be bottom up. Start with a definition of Service. Then define Web Service and then you can easily distinguish between what is a Web service and what is not. Generally, for such discussion, I attack it like this:
Any reusable piece of code which defines a contract for client is a service. A printer driver on your desktop is a service.
Any Service which can be used over the web ( over HTTP in text request/resposne ) is a Web Service.
A RESTful service adds more contraints in terms of VERB vs NOUN separation and concept of Resources.
How Servlets differ from REST is the absence of contract in Servlets and hence Servlets by themselves are not Services.
Nobody can stop a person who wants to implement RESTful Service using Servlets - but it is too low level for REST development in a world where frameworks exist to help ease development !!
ALL Web Restful services in Java world are written over Servlet which is the lower end implementation for handling HTTP. If the transport is not HTTP, it is a Service but not Web Service :)
The answer i think is fairly obvious so the question they gave you is a bit peculiar. Both SOAP-based and REST-full services use HTTP as transport mechanism, so in effect they are web services.
Their difference is that SOAP-based services are more strictly defined by a specification whereby REST-full services are more like an architectural style less constrained in their implementation.

Best way for handle Read HTTPRequst post data on Restful api

What is the best way of save data using Restful web service without using Ajax? As a example I need to add a new Customer to the database using submit button.
What is the best way of transfer data format (text,json,xml) ?
How to read POST or GET data from HttpRequest object?
If you can please give me a example in java .
Thank you
I think you need to separate the concepts a bit. A "Restful Web Service" is a web service designed using REST principals, whereas AJAX is a set of technologies used often on the client side for asynchronous requests to multiple resources (without fully reloading the page). The web service really shouldn't care how the HTTP request is generated, just the contents of the HTTP request.
Now if you're concerned about writing a rest service in Java, I would highly recommend looking into JAX-RS and the reference implementation Jersey. There are lots of examples of how to get up and running. You can use MessageBodyReader implementations are to convert data from the HTTP request entity into Java objects.
Obviously this is not the only way to get started with writing a Restful web service in Java, but is one way.
It's very definitely worth your time to carefully study Richardson and Ruby's RESTful Web Services to learn the REST architectural style. In addition to #ach_l's recommendation to use Jersey, take a look at the Restlet Java framework, which is completely wonderful.

what is spring web services used for

I am building websites in spring MVC. as there are many spring projects , i wanted know what will be scenario when spring web Services is used for.
i mean what can be done with that. Do i really need it for ecommerce site
Your question is really about "web services". For a layman's explanation of what it is all about, read this Wikipedia article.
There are a number of related acronyms that get bandied about:
SOAP (Simple Object Access Protocol) is a protocol for sending requests to a service and getting back a response. The messages are encoded in XML, and send over HTTP.
WSDL (Web Services Description Language) is a service description language for SOAP-based services. It does things like specify what is in the messages, and how the messages are bound to services.
SOA (Service Oriented Architecture) is essentially a system architecture in which the system consists of lots of SOAP services (and others) described using WSDL.
(The proponents of SOA talk about "design principles", but in my cynical view is that this is just a repackaging / recasting of stuff that people have been doing for 20+ years under other names.)
Do i really need it for ecommerce site
Ask your customers. Ask the people whose systems your system will be interfacing with. Ask the vendors whose components you intend to embed in your system.
If you have to use WS then what extra facility it will give
If you have to use WS (e.g. because your site needs to talk to other services that require WS), then you have to. That is sufficient justification.
If you don't have to use WS, then you need to balance the advantages of using WSDL + SOAP against the advantages of some other approach to implementing your web APIs. An SOA expert will probably say use SOA; an AJAX expert will probably say otherwise. And there are other remote procedure call technologies around ... if you really need that kind of thing.
WSDL + SOAP certainly does have some advantages; e.g.
machine readable specifications for your web APIs,
possibility of validation of messages against XML schemas,
an ecosystem of existing WSDL services,
adoption in some sectors of IT.
But it has downsides also; e.g.
WSDL + SOAP have a significant learning curve compared to some alternatives,
XML is a heavy-weight encoding scheme - relatively expensive to parse,
SOAP only pretends to be type-safe (compared with say CORBA / IIOP),
SOAP is not usually used* in browser-based clients; JSON or plain XML are commonly used for AJAX apps,
many people think SOA is over-hyped and steer clear.
* However, it can be used; read these IBM DeveloperWorks Articles.
My advice (FWIW) if your system is primarily a website, doesn't need to talk to SOAP services, and doesn't need to provide a SOAP service API for others .... don't bother. You can always add SOAP service APIs later if you need to.
Spring Web Services is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
More here : Spring Web Services
How to use Spring Web Service : Spring WS
If you don't know what Web Services are, you probably don't need them. Web Services are a way (speaking generally here) for one web application to talk to another. You can formulate a request as an xml document and send that xml to a web service, which is listening on a specific URL and port. The Web Service can then perform some action based on this document, and respond back with an XML document. It's commonly used as a means for integration between applications.
If you're building a simple e-commerce site, which does not integrate with other live web products, then likely you don't need Web Services. Spring Web Services is simply an API/library to make reading/writing web services easy.

web service and web application

I am new to web serivce. I have written a few clients using AXIS2 but nothing more. Now I have to create some service that will be consumed by others. We have a web application written using wicket.
Does my webservice need to be a part of the web application. Can it be a deployed seperately, but still use the same code that is used by the web application.
any tips of how to start including security, authentication etc. Any reference to reading material, tutorial is greatly appreciated.
Taking the questions one at a time:
Does the webservice need to be part of the web application? No. It can be a completely separate project with it's own deployment.
Can it be deployed separately? Yes, see #1.
Can it use the same code as the web app? Yes. This is a matter of how you reference the web app. You might consider branching the code, or just building it in to the web app to begin with.
A couple of resources:
RESTful webservices with Wicket
Web service API for Wicket
Bear in mind, I've never used wicket before so I have no idea if the above links are worthwhile.
Regarding security. You usually provide a web api "key" of some sort to your clients. That key is then passed in to every api call which you then validate for both authentication and authorization. This is how most systems work.
Also, just like with web apps, the calls to the API should go over an SSL connection in order to try and prevent anyone from eavesdropping on the conversation.
As far as logging, this is no different than logging you would set up for a normal web app. There are plenty of logging tools out there like log4j.
Short answer: Generically, yes, you can deploy your web service as part of your web application. You should think of your web service as another "view" on your business logic. If you have followed good patterns (e.g. putting your business logic in a library, not controllers) this shouldn't be too hard.
You may want to "enforce" this by putting shared business logic in one library, and then split the web service and web application into another project.
There are really too many options for web services to list them all, but here's a place to look as a tutorial:
http://static.springsource.org/spring-ws/sites/1.5/reference/html/tutorial.html
Follow the below link that explains how to expose your ASP.Net web application functionality as a web service. The below article takes TrendsInInvestment web application to explain the procedure.Features like authentication,caching and pagination has been included while implementing web service.
1)Link for article.
http://securityresearch.in/index.php/tutorials/how-to-expose-your-asp-net-web-application-functionality-as-awebservice
2)Link for the modified web application,web service and its sample code .
http://securityresearch.in/index.php/projects/f_security/trends-in-investment-web-service-1-0-is-now-available

Categories