TL;DR
JAX-WS is meant for XML based web services such as SOAP. JAX-RS does not have the same restriction.
JAX-WS is generally geared towards server to server interactions with well defined contracts (WSDLs) and usually when the service and client side are from separate groups. It is very resource intensive so it isn't feasible for client-to-server interactions where the network or client device capability is less than optimal.
JAX-RS is geared towards client to server interactions, although server-to-server is okay. As it has little service obligations, it can be tuned to whatever the client needs are.
More info
The JAX-RS API only provides code-first approaches, whereas JAX-WS allows for both code-first (generally not recommended) and contract-first using WSDL files (more commonly recommended).
JAX-RS 2.0 introduces the client API which is a smart wrapper for HttpUrlConnection that has a lot more mapping capability, JAX-WS is also a wrapper, but the data it deals with in the reference implementations is just XML.
JAX-RS has the advantage of creating APIs that are simpler to create and digest messages for in different browsers and mobile devices, namely JSON structure. It does not introduce the notion of an envelope and uses HTTP for it. It does not introduce cryptography or security, it uses HTTPS for it.
JAX-WS though it runs on HTTPS for cryptography provides additions for security using WS-SecurityPolicy etc. In addition, contracts are firmly established using WSDL and can be verified outside the application using ESBs such as DataPower.
So what to choose
JAX-WS is generally geared towards server to server interactions with well defined contracts (WSDLs) and usually when the service and client side are from separate groups. It is very resource intensive so it isn't feasible for client-to-server interactions where the network or client device capability is less than optimal.
JAX-RS is geared towards client to server interactions, although server-to-server is okay. The only contractual obligation between a client and server is the message and the request headers. As it has little service obligations, it can be tuned to whatever the client needs are.
However, using RESTful service APIs is akin to doing meta-programming like Ruby and Python which delays problems to run-time as there is no defined schema agreed and technically enforced upon by the two sides. As such I don't recommend RESTful services everywhere, but I would recommend it if I had control of the two sides which normally happens when you do build a web application that uses static HTML/CSS/JS and talks with a RESTful server for the data.
