The only thing I’d add is that new versions should be rare; the real value of REST (and the rest, ahem, of the Internet architecture) comes from stable, well-understood formats, not localised ones that change every week.

thank dude!

Cheers Chris

Just make log(Object obj) do an instanceOf check for throwables and get rid of the log(Throwable e) version.

You get the performance of an early-bound language and all the optimizations that the compiler can perform on a strongly-typed language AND you get the ability to do late-bound operations through the reflection system, though I admit that using reflection results in verbose code ( shouldn’t matter since it is rarely used )

I just tried your solution and it worked without any problems. I was able to stop the process by killing it as you described. I even closed the command window and it continued to run and that’s what I wanted. Before that I was struggling to find a solution for it on AIX 64bit. I tried a solution from tanukisoftware but it did not run on 64bit version, although it was fine on windows platform. Thanks

I think in the situation you describe using URIs as the IDs is really compelling. The redirection capability of HTTP can be leveraged to provide excellent forward compatibility.

If your future URI revamp is so simple that the clients would be able to handle, you could implement a simple mod_rewrite rule on the server and not have to mess with the clients at all. If however you ever need to revamp the URI patterns is some really fundamental way you can create, as part of the migration, a mapping between the old URIs and the equivalent new URIs.

That combined with a client that respects the redirect type and you have a really scalable system. By that I mean, any client that stores URIs should updated them if it ever gets a permanent redirect when requesting that URI. If the client has some URI and a year later makes a GET request against it and receives a 301 “Moved Permanently”, it would updated that replace the old URI with the new URI in it’s internal storage.

These mechanisms mean that you do not need a non-standard, or out-of-band, way to communicate URI pattern changes to the clients.

If we change our root URI, all the links bust. If our clients use “base URI + id” to construct URIs, then when we change, at least they just have to change the base URI instead of having to fix up a billion stored links (since the stored IDs would not have changed, though the URI did). [BTW, we’re looking at using something similar to “ark” to resolve broken links from the ids using a namespace at the beginning of the and a “resolver” service].

When the clients are only using URIs temporarily, then it makes sense for them to get those full URIs from the server on the fly. But if they are storing them, then I’m still struggling with the best approach.