This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
WSDL vs REST Pros and Cons
can any one explain what is the difference between Restful web services and WSDL(Web Service and Description Language). And which one is more secure and how?
Thanks
WSDL is used to describe SOAP services. You're really asking for a comparison of SOAP and REST.
There is no inherent security difference between SOAP and RESTful services. Most likely any security issues will be with your specific implementation of them.
SOAP is more like RPC - it focuses on calling commands on a remote server. REST is resource oriented - you interact with the server by adding, retrieving, updating and deleting resources on the remote server, which corresponds to actions.
eg. With SOAP service you might call an updateAccount(account_id, details) method to save changes, but with a REST service you might PUT information to /account/<account_id>.
In Java, JAX-RS is a good place to start with RESTful services.
WSDL "Web Services Descriptor Language" is the standard for defining the content and behavior of SOAP based web services. It is part of a collection of WS* standards that define "Web Services". These standards cover discovery, transport, message format, authentication, non-repudation etc. etc.. These are formal standards managed by W3C.
REST is a style of network programming where every request is made in the form of a valid URL to identify the "key" of the object in combination with an http GET, PUT, POST, or DELETE action to identify what you want to do to it.
REST is a style rather than a standard messages can be in XML, JSON or any format you choose.
My opinion is that REST is great for doing simple things simply. SOAP etc. is great for complex "enterprise" level interactions with sophisticated security and workflow requirements, but, its overkill for simpler services.
As for security REST does not help you. But using standard web security (sessions, cookies, SSL etc. ) you can secure a RESTful service pretty well.
SOAP has built in bulletproof security but its configuration heavy requiring LDAP servers and managing public/private key pairs. Unless you really need it its best left alone.
Related
I have worked on RESTful Web Services at a high level (not very exhaustively), coded few REST based web services.
To begin my journey in RESTful WS, I read online articles (wiki, online tutorials etc.) and I came to know that it is an architectural style specifying constraints and when applied to web service induce desirable properties, such as performance, scalability etc. Ok, this is the theory part of this concept.
A simple example using JAX-RS:
#Path("/simple")
public class SimpleRESTService {
#GET
#Path("/{param}")
public Response getMsg(#PathParam("param") String message) {
String output = "Jersey say : " + message;
return Response.status(200).entity(output).build();
}
}
My doubt is:
If REST is architectural style (and using those guidelines build RESTful web services), what does JAX-RS do? To what I understood, REST is just architectural style and not any specification, what does JAX-RS has to do with this? I am having difficulty in understanding the relation between these two entities.
Can anyone help me understand this in simple words.
REST is indeed an architectural style of building web services independent of application-layer protocols (it could be implemented over FTP or HTTP as well).
JAX-RS is just a standardized API of Java EE with which you can easily implement RESTful services in Java. It is a toolkit for a developer to lift the burden off his shoulders, and as part of Java EE, it is implemented in application servers such as WildFly out of the box.
But note that it is just as possible to create REST services in frameworks like Spring using the Spring Web MVC and Spring HATEOAS modules.
Edit:
Although REST is a well-defined architectural style, it is (as you mentioned) not a specification so there is a lot of foggy areas about it among developers.
In a nutshell, all it states is "Hey man, if you use the communication protocol (say HTTP) this way and this way, it will be very convenient for you to change and scale and it will be very straightforward for the clients of your service to talk to you".
JAX-RS gives you the ability to define service endpoints with dynamic parts (eg.: /api/jediknights/{id}, so that the id could be anything), makes it easier to respond to the client in the format of your (or your client's) desire, like XML or JSON. It provides convenient wrapper objects to wrap your response body along with status codes and headers and many other things of convenience.
The catch however is: it is still your responsibility as a developer to adhere to the principles stated by the REST style. Nothing is really enforced upon you by JAX-RS.
To be fair, you could even achieve a RESTful web service by only using the somewhat lower-level Servlet API. JAX-RS just hides the unnecessary details from you and will make your life easier.
I hope it became a bit clearer :)
Java API for RESTful Web Services (JAX-RS), is a set if APIs to
developer REST service. JAX-RS is part of the Java EE6, and make
developers to develop REST web application easily.
You can read some more here: http://www.mkyong.com/tutorials/jax-rs-tutorials/
I am studying for the Spring core certification and I have some doubts related how REST web service and I am studying it to apply to Spring framework.
So I have some doubt related to this question founded on my study material but I can't find an answer.
So the questions are (I don't know it these questiona are related each other):
Is REST secure? What can you do to secure it?
Does REST work with transport layer security (TLS)?
I have understand how a REST webservice works and I know that it use the Http method to access resources and implement CRUD operation but what means asking if REST is secure? What is meant by secure in this specific case?
And what exactly is a TSL in REST?
1. Is REST secure? What can you do to secure it?
REST is a paradigm. It's not a finished protocol or an implementation.
There are mechanisms to secure RESTful webservices (one would be TLS), but by default REST doesn't say anything about it.
The OWASP gives a good overview over REST security topics and how to secure a RESTful webservice:
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
What is security?:
Please note that there are different security objectives in information security:
confidentiality
integrity
availability
All would need different security measures. Some can not be handled by the webservice (REST) alone. (e.g. availability would mean that the server itself is secured and you have security measure agains dDoS attacks.)
It's not really well defined what REST is in detail, it's not a official standard or a specification. I would say that REST per se is not secure. There are mechanisms you can build around it to secure it (like TLS, token authentication). Many of these measure have nothing to do with REST directly.
2. Does REST work with transport layer security (TLS)?
Yes. Transport Layer Security can encrypt the communication to a RESTful Webservice and authenticate the server to a client. (confidentiality and to some extend integrity)
1. It depends. Security is about tradeoffs, not a simple yes/no question. REST is not inherently secure or insecure; it depends on how you implement it. One example is SQL injection attacks: the use of REST has no bearing on whether the system prevents them. Another example is authorizing access: REST does not inherently limit access to the resources it exposes. If you need a guarantee that those resources can only be accessed locally, using REST will make it harder to ensure that.
2. Generally yes. Off-the-shelf servers support TLS, but a completely written-from-scratch program using REST to communicate might not implement TLS code (this is a rather unrealistic scenario, but I'm including it for the sake of completeness).
I saw these two links:
1.SOAP vs REST
SOAP vs REST 2
I understood the difference between the two. But I also heard about WADL (https://wadl.java.net/), which are used along with REST to provide a contract ( similar to SOAP WSDL does)
Now I have two questions:
REST is also adheres to the data type that is going to receive or transmit by WADL, which now acts very similar to SOAP ( with WSDL ).
If REST with WADL and SOAP are similar, which one to use?
Thanks in advance.
SOAP (Simple Object Access Protocol)
REST (Representation State Transfer)
SOAP and REST can’t be compared directly, since the first is a protocol and the second is an architectural style.
The main difference between SOAP and REST is the degree of coupling between client and server implementations. SOAP works like a custom desktop application, tightly coupled to server. There is rigid contract between client and server and everything seem like breaking is any of the side is changed. But, REST client is more like a browser. It’s a generic client that knows how to use a protocol and standardized methods. If done right, there would be less coupling.
A client is supposed to enter into REST without prior knowledge of the API, except for the entry point and the media type. In SOAP, the clients need to have the prior knowledge of everything it will be using.
REST is protocol independent. It’s not coupled to HTTP. We can use it for any protocol for which there is standardized URI scheme. But, SOAP itself is a protocol.
SOAP only supports XML, but REST supports different format like text, JSON, XML etc. And we know if we use JSON then definitely we will be in better place in terms of payload.
SOAP can use any generic transport (HTTP / HTTPS) or RPC (Remote Procedural Call). But, REST uses only HTTP/HTTPS
SOAP can’t use REST. But, REST can use SOAP similar to HTTP or any other protocols
SOAP used services interfaces to expose the business logic. REST used URI to expose the business logic
In Java, JAX-WS is for SOAP web services. But, Java JAX-RS is for REST web services
SOAP defines the standards to be strictly followed. REST doesn’t define any standards like SOAP
SOAP requires more bandwidth and resource than REST. REST required less bandwidth and resources.
SOAP defines its own security. REST inherits security measures from underlying transport
SOAP is less preferred these days as compared to REST
RESTful and SOAP WebServices are fundamentally different.
In short - SOAP is a typical RPC based call where you hide your request action and details within the XML document of the SOAP body. Wheras pure RESTful webservie totally rely on HTTP methods to perform an action on server.
Although WADL is not yet widely adopted and not really a standard but the theory behind it is to simply help tools to generate some code, and it aims to promote reuse of applications beyond the basic use in a web browser i.e. machine-to-machine communication (still using HTTP protocol).
Though this might appear as a duplicate of Java Web Services , I would like to know Where to start and to continue.In the past, I have invested so much of time to find where to start but I wasn't able to. There are so many jargons and chaos (at least for me!) while reading the pages about web services. There are so many terms - like JAX-RPC, JAX-WS, Axis, Rest, Servlet as WebService, EJB's as Web Service and other terms that I don't know. Can this User group consolidate and give a highlevel overview of Java Web Services which is easy to understand and follow? I appreciate your kindness and thanks for your help.
That's indeed a bit a jungle to understand web services. The wikipedia page is decent, but still lacks some elements.
I've flagged this answer as community wiki, so feel free to update it, or correct it. It's only a basis.
A bloated term:
First, the term web service is used to refer to many thing. While many people use it to refer to SOAP-based web service, the term can be used to denote any service provided through a web interface; this is a source of confusion.
Implementation and design style:
SOAP-based -- SOAP is still the de-facto standard for web services. SOAP is protocol on top of HTTP that describes the exchange of message and exception. SOAP grew from something simple to something very complicated with all the WS-* standards that have been added later. The most important are: WS-Policy, WS-Security, WS-Addressing, WS-Transaction. Another important spec is MTOM for large message.
RESTful -- The term RESTful relates to the fact that the service is stateless and all relevant information is passed as parameter. Also instead of using a protocol like SOAP, plain HTTP verbs are used, e.g. Get, Put, Delete, Update.
Stateless -- WS are usually stateless. Business processed sometimes rely on so-called correlation identifiers (with WS-Addressing) that are used to match requests and response together; this is the same idea like storing a session identifier in a cookie because HTTP is stateless.
Stateful -- There are some proposal to have stateful WS, but I don't know much about it.
Implementation and technology stacks:
Servlet -- The lowest-level way to implement a WS: you basically parse the request and spit the HTTP response all by yourself.
EJB -- Since EJB3, EJB can be exposed as web service very easily. Needs an EJB container, of course.
Apache Axis -- Used to be a popular technology stack which is declining now.
Apache CXF -- Another popular choice.
JBossWS -- Yet another popluar choice.
JAX-WS -- The official web service stack from Sun, very good. So far I know, this replaces JAX-RPC which was simply renamed JAX-WS.
Related concepts and jargon:
WSDL -- Defines the contract/interface of the web service, in case of SOAP-based WS.
Contract-first -- Refers to the fact that that a technology is able to support any WSDL provided upfront. On the contrary to an implementation technology which will generate the WSDL based on the implementation of the web service, in which case the WSDL can not always be customized as necessary
Profile -- To simplify this mess, they've introduced profiles which are groups of related specifications/capabilities that need to be supported for interoperability. The main one is WS-I Basic Profile.
UDDI and discovery -- It seems like some people thought the web service would be published in a public register so as to be discoverable by potential consumer. I don't think this vision gained much momentum.
The best explanation I know for "contract first" web services is Spring web service module.
Basically I need webservice where client can request with id one boolean value from our webservice. What technology would be most suitable for this small API? Of course it is possible that there will be more functions to interface, but now we need only one function. It also needs to have authentication, so that only auhtorized clients can access service. And every client have different auth credientials.
What would be good technology for this purpose?
I am using resteasy to build my webservices and it is pretty easy to use ... just need to use annotations on my methods to deliver the webservices.
Here is a comparison of different JAX-RS frameworks. Take a look at it
First of all: authentication and authorization. Don't do it yourself, pick an app server or servlet container and configure it to do the job.
For the web service....
The simplest thing to do it just implement a servlet that responds to a POST (not a GET if request modifies internal state) and returns the result in the body. This way you don't need any frames works, no learning to do (if you already know servlets). The downside is it won't scale as you add more features, and your not using enough buzz words.
If you want a SOAP based webservice, then look at JAX-WS. Now that it's backed into java 6 it's pretty easy.
At the simplest level JAX-WS lets you put a few annotations on your class, like #WebService, and it auto generates a wsdl and exposes an instance of your class via the web service.
There is plenty of documenation out around how to do it:
http://java.sun.com/webservices/docs/2.0/tutorial/doc/
http://www.java-tips.org/java-ee-tips/java-api-for-xml-web-services/developing-web-services-using-j.html
http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
JAX-WS + any servlet container (Tomcat is usual choice)
#WebService(targetNamespace = "http://affinity.foo.com", name="RewardsStatus")
#SOAPBinding(style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
public interface RewardsStatusIF {
#WebMethod(operationName="GetLastNotificationDate", action="urn:GetLastNotificationDate")
#WebResult(name="return")
public Date getLastNotificationDate() throws AffinityException;
...
Actually, you don't even need a servlet container. JAX-WS has a way to run the service under a standalone Java application. It has some limitations (I have failed to make a stateful service work), but it's
very simple to create.
Given that you tagged your question as "Java", I suggest Jetty. It is a very good small servlet engine. It has support for sessions, so adding authentication should not be a problem.
If you are using Java 6, there is already a HTTP Server builtin, it supports Http authentication. That's all you need. Check out,
com.sun.net.httpserver
You could use some restful framework like jersey.
An alternative to SOAP-based web services with JAX-WS would be JAX-RS (for RESTful web services).
We have a lot of scenarios on our project where we want small amounts of data available via simple HTTP URLs while the app is running and in my experience, Restlet (http://www.restlet.org/) seems to be one of the easiest things available for setting up simple "web-service"-like interfaces (RESTful interfaces) within Java apps.