Develop Reference

Consuming REST service that doesn't offer WADL

I need to work with a REST service that has a relatively simple and fixed (meaning predictably not very variant structure), yet I can't find a WADL anywhere on their site. I have previously worked with SOAP services, which had a decent WSDL and I used it to generate my Java classes to which my client app was marshalling the service data using Axiom2.
My question is: is there an easy way to reverse engineer a WADL with which to easily generate corresponding Java classes if the site is lacking one, using some implementation of JAX-RS (e.g. Jersey)? Another way to ask it is: given only a REST service, no WADL, and some form of JAX-RS, what is the easiest way to generate marshalled classes on the client side?
Currently, as the structure is simple, I do it the hard way of using straight DOM from Java SE (org.w3c.dom) to parse the document. It works fine but I do not like all the traversing I have to do within the document structure and I feel like I reinvented the wheel. I am sure there is a more elegant way.

If you're just doing this once why not just do it by hand? If you need to do this regularly then you may be out of luck wrt WADL (as an aside see: https://softwareengineering.stackexchange.com/questions/133145/should-i-use-wadl-to-describe-my-restful-api).
Are you just trying to generate Java classes for the DTOs from the service? In this case you could take some sample XML from the service and use this to generate a possible XSD (maybe using trang). Then use XJC to generate the corresponding Java classes.

If the REST service is implemented in Jersey, Jersey should auto generate the WADL at runtime. The default location is http://server:port/appcontextroot/application.wadl. If the REST service uses other implementation such as RESTEasy, you are out of luck. https://issues.jboss.org/browse/RESTEASY-166

Publishing/ Documenting Spring-REST API

I have looked around a bit on stackoverflow as well as google, but couldn't find any good tool that can document SPRING-REST api. Tried using enunciate, but it barfed out on spring annotations it couldn't recognize. Does anyone know of a good tool for documenting a spring RESTful api ?

Typically you need not document your REST API. Your clients should be provided with the specification of the media type you are using (think Atom or OpenSearch for example) and only rely on the information given there.
As soon as you document anything about a specific service, you are coupling your clients to that documentation (and that service). The result being that your service's ability to evolve is now limited by the amount of out-of-band information the clients have baked in their code (based on your API description).
IOW - when was the last time you needed a service API description to make your feed reader talk to an AtomPub service?
Jan
P.S. The theoretical backgrounds I summarized in [1]. Look specifically at the difference between HTTP Type I/II and REST. And Roy's [2] is a MustRead on this.
[1] http://www.nordsc.com/ext/classification_of_http_based_apis.html
[2] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Just document everything that needs to be documented from a client developer perspective. And please don't take advice like "you need not document your REST API" seriously. This is a pedantic guidance and not useful in the real world.
Every successful API out there is well documented from client developer point of view. Any API that is hung up on pedantic notions is bound to turn off client developers.
See Chapter 14 of my "RESTful Web Services Cookbook" (http://shop.oreilly.com/product/9780596801694.do) for some examples.

Try using Swagger. It provides few of its own annotation that work well with Spring MVC rest annotations.

JAX-RS implementation of link/element expansion?

While reading documentation of Google Data API and Atlassian REST API, I found interesting functionality - link (or title, element expansion) - http://bit.ly/i3rKMw. I would like to implement this functionality in my Java project of web service server for our IS, but I can't find any proper solution or advices for implementation. My project is quite big with many services so I need some robust and most automated solution. I was thinking about how to implement it like an extension for RESTEasy and JAXB, but it seems to be very complicated.
Do you know some opensource projects which implements this functionality or any advices which could help me?

Resteasy already provides an annotation based solution for this:
http://docs.jboss.org/resteasy/2.0.0.GA/userguide/html_single/#LinkHeader
This was added to version 2.0

I don't think that any JAX-RS framework can provide such logic.
It actually a business logic: when you receive expand query parameter, expand the relevant element/section.
You'll need to implement it yourself.

Guaranteeing that a .NET WCF Service can be consumed by a Java client

I am creating a WCF Service that will be consumed by both .NET and Java client applications.
We do not have any Java experience in the team, so are looking for guidelines or rules to follow to ensure that we do not accidentally include any types in our WCF Service interface or do anything else that would preclude it from being consumed by a Java client application.
Are our worries well-founded? If so, what should we be wary of?
Edit
One example of a concern is whether a .NET DateTime value is represented in the service interface in a manner that can be correctly understood by a Java client.
Edit2
A second example of a concern is the use of any nullable value types (bool?, int? etc).
Edit3
At present some of our development teams are hand-writing .xsd files to define the various objects that the WCF interface methods will take as arguments and return as return values. They are then using xsd.exe to auto-generate C# classes from these.
The rationale behind this is that it guarantees that the generated classes won't contain anything that is .NET-specific.
The downside is that this adds a development burden and also precludes us from documenting these classes using <summary> tags (.NET equivalent of javadoc comments).

The recommendation to start with XSD is a good one. That will not guarantee compatibility on each side, as XML Schema is really big and no web services stack supports all of it. (Example: lists).
So, start with XSD, but confine yourself to mainstream types. Primitives, complextypes composed of primitives, arrays of same. You can safely nest complextypes and arrays. (arrays of complextypes, complextypes that contain arrays or complextypes, etc).
Stay away from restrictions, substitution groups, lists, derivations, and any other XSD esoterica. Even XSD enumerations should be avoided.
About dateTime:
It's not enough to use a nullable datetime. There are formatting concerns as well. The .NET DateTime is a higher resolution quantity than a Java Calendar and as a result, shipping a .NET time to Java can result in de-serialization exceptions on the Java side. (EDIT: using the DataType="dateTime" decorator in the XmlElement attribute on the .NET side can make sure you serialize properly)
Some old advice on that.
Finally, it is not true that you cannot use in-code XML doc on the classes that get generated. With C#'s partial classes, you can write separate code from the generated classes with the in-code doc you want. Even if you re-gen the code, your partial class code will remain unchanged. EDIT: When you compile, the doc will appear on the classes.
EDIT: Someone asked, if using XSD-first is not enough to guarantee interop, why use it? My answer: it is not a guarantee but it is a good step, it helps. It keeps you away from designing interfaces in code (either Java or C# or VB, etc) that expose platform-specific things like .NET DataSets, generic Dictionaries, Java ResultSets, etc, all of which present interop problems. There are still pitfalls in the more marginal parts of XSD, but you can usually avoid those with thoughtful design.
I should have mentioned in my original answer that you can apply an iterative process to the development of the interface. Design in XSD, then generate (client) stub and (server) skeleton code from the XSD+WSDL, then adjust and do it again.

Using basicHttpBinding endpoint will guarantee that any SOAP 1.1 compatible client will be able to consume your service.

Use DateTime?, i.e. a nullable struct. Java does not have the notional of complex value types (i.e. structs). I believe there are ways to specify in the WSDL not to allow nulls, but I think WCF doesn't do it out of the box.
Use arrays instead of collections. If I recall correctly, the collection types do not translate very well over SOAP, but array types do quite well.
You should get a copy of Eclispe or Netbeans. After you create a prototype WCF service, run the web service wizard to create your proxies. Examine the object model for any major defects with particular emphasis on complex objects or non-primitive types (treat string as a primitive).
The learning curve to do that with Netbeans or Eclipse is pretty flat, so it's not a huge burden.
Edit: The other potential problems are with the bindings. If you stick with HTTP(S), you should be good... start going to the alternatives like TCP or MSMQ, you'll have to do a lot of work in Java. Also, some of the security features don't interop in all cases, such as using NTLM tokens... Take an iterative approach. Start with a simple HTTP w/SOAP binding with no security and go from there.

Does WCF provide standard SOAP interfaces? If it does, getting Java to talk to it should be a doddle.
Re: Edit1: The WSDL / XSD will use a standard date time format (Calendar at the Java end, a formatted datetime string in the SOAP, DateTime in .NET), or you could force it into a string format of your own choosing.
Read up on the Apache Axis (1.4 and 2.0) documentation for Java web services. It's very easy to use to get a Java web service client set up from the wsdl/xsd that your web service will provide.
Edit3: In Java you would define a Java model (with all your favoured documentation), then run Java2WSDL (preferably as an ANT/Maven task) to create your WSDL (however I have found you need to hand-reorder the fields in it). Axis 2 supports Collections and Enums just fine, Axis 1.4 likes Arrays and hand-rolled Java 1.4 style enumerations. From this WSDL you would create a server-side skeleton using WSDL2Java in which the only thing you need to do is implement your business logic.

Which SOAP XML object serialization library for Java would you recommend?

Which Java SOAP XML object serialization library would you recommend for Java object exchange with other platforms / languages (.NET, Delphi)?
Communication scenarios could look like this:
Java object writer -> SOAP XML text -> .NET or Delphi object reader
.NET or Delphi object writer -> SOAP XML text -> Java object reader
I know there is the XStream XML serialization library and JSON as alternative solutions, however since Delphi and .Net have built-in support for SOAP XML serialized objects, this would offer a 'standardized' way with support for advanced features like nested objects, arrays and so on.
Edit:
Meanwhile, I found JAXB - (https://jaxb.dev.java.net/), JAXMe, and JiBX - Binding XML to Java Code(http://jibx.sourceforge.net/). But they do not generate SOAP serialized XML by default.
A possible solution would be a web service library which is able to run without a HTTP server, and offers a simple file interface for the SOAP XML content (not a complete request, just a serialized object). Axis 2 and CXF look very interesting.

I prefer JAX-WS (with JAXB 2.1 databinding) over the other liberaries I've used (JAX-RPC, Axis 1 and 2, but not XFire). The JAXB 2 databinding uses generics, which makes for a pleasant mapping of properties with a maxoccurs > 1. JAX-WS itself is reasonably well documented and provides a reasonably good API. The method and parameter annotations can get a bit out of hand in some cases - XML hell in annotation form. It usually isn't so bad.
One of the nice aspects of the JAX-WS stack is project Metro, which Sun co-developed with Microsoft and interoperates well with the web service support .NET 3.0, going so far as to implement MTOM in a workable fashion.

I would recommend CXF. It is a very good services stack and includes JAXB data binding and JAX-WS support. You may want to look at an open source integration platform like Mule that includes CXF (also supports Axis and XStream) if you need more advanced transformation and routing of your messages. It is lightweight and can be embedded or run without an app server.

In addition to Axis2 which works ok, Sun's JAX-WS (version 2) and Apache CXF (nee XFire) are worth checking out, it Soap is your thing. CXF may be the most mature of the 3, so that's my favorite, but all 3 are pretty good.

The standard library for this would probably be Apache Axis1. I would advise using axis2 instead of axis 1.4- though it works pretty well.
Bearing in mind that the all of the SOAP extensions make the dream of interoperability just that... a dream.

I think you have answered your own question.
XStream (outputting as JSON) is a nice clean solution. If you alias types you get a clean output format. After that it doesn't matter which SOAP stack you use so long as it is nice and interoperable with Delphi/.NET.