application/x-java-serialized-object

[michael]

Probably reststar can not be java specific.
Specing multiple representations for a resource might be difficult.
Perhaps the spec should start with 1 representation: you GET what you
PUT/POST.
Or something non binding, like a server may provide alternate
representations of a resource.

I don't like that you can't PUT what you GET.
Well... as I read the current api, you can, but you would lose your
java object,if you try to update it with, for example, a json
represenattion.

Michael

[Bill Burke]

Off topic: JAX-RS group was talking about defining a new media type
for Java. x-java-serialized-object ain't good enough. We should be
able to have classnames, even svuids.

On topic: What you want to do is be able to PUT multiple
representations to the same URI so that you can use conneg?

Another approach would be to use Link headers:

http://tools.ietf.org/html/draft-nottingham-http-link-header-06

use the "alternative" relationship and link up alternate
representations

[Michael Neale]

In Infinispan the x-serialized-object isn't ideal - its more for
getting java objects in binary ser form if they got into the cache via
some other distributed means (ie the RESTful server is just a "window"
into the Infinispan grid). What is preferred is content type
negotiation and it can return it in something useful like json/xml to
a REST client.

What would be a reasonable use of puting in and getting back binary
serialized objects via REST over some native interface? (happy to be
convinced it matters, and why a better media type is needed, as Bill
mentions, at the moment I just don't see it).

The main thing that interested me about the media type was how to
index it (which is a whole separate topic) - otherwise (really) I
wasn't that worried - it will just store and return what it is told.
Not sure if much more is needed to be honest?

[Bill Burke]

Well, it would be interesting for versioning or for getting different
object models (transformations).

i.e.

java/class;name=org.jboss.Foo;svuid=3324222

It should be thought about a bit more, but thats the idea.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Michael Neale]

In a sense I have done that using the usual mechanism (but only to
decide between XML, JSON or serialized binary format).

That seems reasonable - but I think anyone who is using java at the
other end wouldn't necessarily want to use HTTP to get at the data
(they may) - and if they don't, then they would want the same sort of
ability in a native API.

I don't think the java specific stuff would interest potential users
of this type of caching ?

[Bill Burke]

My personal opinion is that rEST should be used as the distributed
interface even Java to Java. There's no reason that serialized Java
objects couldn't be exchanged in such a scenario. RMI just doesn't have
as many of the features as HTTP has, i.e.:

* caching (Cache-Control semantics)
* conneg
* conditional puts/posts

etc. etc. etc.

[Michael Neale]

Perhaps, I have used HTTP over RMI since 2002 (using just serialized
objects often) and it was great, so I agree.

However, probably this forum isn't the optimal place unless it is to
be java centric?

[Bill Burke]

It is up to you. There's nothing stopping you from defining a Java
media type here that is specific to a caching interface for Java to Java
communication. Its no different, IMO, than deciding to use JSON because
it works well with Javascript. There's no reason that both can't be
supported from the same resource.

BTW, i thought RMI over HTTP was just a tunneling protocol? There's a
big difference from leveraging HTTP as an application protocol to just
tunneling over it.

I "saw the light" when I started thinking of HTTP as a messaging
protocol. There are so many tools, libraries, services, and frameworks
you can leverage after you've decided to use HTTP as your messaging
protocol.

[Michael Neale]

No I used HTTP and discarded RMI all together. Was pre common
understanding of REST days, so probably was more akin to tunnelling
(but I didn't hide the fact that it was http, used it as best I
could).

How does one go about creating a new media type in a globally safe
fashion (name collision wise)?

[Bill Burke]

Michael Neale wrote:
> No I used HTTP and discarded RMI all together. Was pre common
> understanding of REST days, so probably was more akin to tunnelling
> (but I didn't hide the fact that it was http, used it as best I
> could).
>
> How does one go about creating a new media type in a globally safe
> fashion (name collision wise)?
>

Not sure, go see if its registered? If not, register it? I think you
also have to write a RFC or something. no idea really.

http://www.iana.org/assignments/media-types/