XML output differs from JSON #83

Closed
michael-schnell opened this Issue Jan 4, 2014 · 15 comments

Comments

Projects
None yet
4 participants
@michael-schnell

Several attributes are only available in JSON (eventType, data, ... ). I'd expect the content to be identical as it's just a different representation of the same data structure. Or is this by intention? If so, this should be documented somewhere with a big exclamation point.

Example:

Request "http://127.0.0.1:2113/streams/chat-GeneralChat?embed=body" with header "Accept: application/json":

    {
      "eventType": "UserJoinedChat",
      "eventNumber": 0,
      "data": "{\r\n  \"time\": \"14:15:28\",\r\n  \"user\": \"John Smith\"\r\n}",
      "streamId": "chat-GeneralChat",
      "isJson": true,
      "isMetaData": false,
      "isLinkMetaData": false,
      "positionEventNumber": 0,
      "positionStreamId": "chat-GeneralChat",
      "title": "0@chat-GeneralChat",
      "id": "http://127.0.0.1:2113/streams/chat-GeneralChat/0",
      "updated": "2014-01-04T13:15:29.0288091Z",
      "author": {
        "name": "EventStore"
      },
      "summary": "UserJoinedChat",
      "links": [
        {
          "uri": "http://127.0.0.1:2113/streams/chat-GeneralChat/0",
          "relation": "edit"
        },
        {
          "uri": "http://127.0.0.1:2113/streams/chat-GeneralChat/0",
          "relation": "alternate"
        }
      ]
    }

Request "http://127.0.0.1:2113/streams/chat-GeneralChat?embed=body" with header "Accept: application/xml":

    <entry>
        <title>0@chat-GeneralChat</title>
        <id>http://127.0.0.1:2113/streams/chat-GeneralChat/0</id>
        <updated>2014-01-04T13:15:29.0288091Z</updated>
        <author>
            <name>EventStore</name>
        </author>
        <summary>UserJoinedChat</summary>
        <link href="http://127.0.0.1:2113/streams/chat-GeneralChat/0"
            rel="edit" />
        <link href="http://127.0.0.1:2113/streams/chat-GeneralChat/0"
            rel="alternate" />
    </entry>
@jen20

This comment has been minimized.

Show comment Hide comment
@jen20

jen20 Jan 4, 2014

Owner

For the most part you shouldn't be using embed=body or embed=pretty - they're mostly there to support the UI. That said I'll have to look over the code to see if there's a specific reason it's not possible with XML (I imagine we'd break the atom schema if we did it though).

Owner

jen20 commented Jan 4, 2014

For the most part you shouldn't be using embed=body or embed=pretty - they're mostly there to support the UI. That said I'll have to look over the code to see if there's a specific reason it's not possible with XML (I imagine we'd break the atom schema if we did it though).

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Jan 4, 2014

Owner

My guess is it's using the atom controller on accept: application/xml

On Saturday, 4 January 2014, James Nugent wrote:

For the most part you shouldn't be using embed=body or embed=pretty -
they're mostly there to support the UI. That said I'll have to look over
the code to see if there's a specific reason it's not possible with XML (I
imagine we'd break the atom schema if we did it though).


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-31578647
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

Owner

gregoryyoung commented Jan 4, 2014

My guess is it's using the atom controller on accept: application/xml

On Saturday, 4 January 2014, James Nugent wrote:

For the most part you shouldn't be using embed=body or embed=pretty -
they're mostly there to support the UI. That said I'll have to look over
the code to see if there's a specific reason it's not possible with XML (I
imagine we'd break the atom schema if we did it though).


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-31578647
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

@michael-schnell

This comment has been minimized.

Show comment Hide comment
@michael-schnell

michael-schnell Jan 4, 2014

Yes, breaking the ATOM schema is possibly the cause. But if the two formats are incompatible, this should be documented in the Wiki (https://github.com/EventStore/EventStore/wiki/Reading-Streams-%28HTTP%29) with a big exclamation point.

Other point: If not using "embed", how do I efficiently read all events of a stream? One example is a "replay" operation for a view. Hundreds of HTTP requests for reading the content of single events wouldn't be very efficient.

Yes, breaking the ATOM schema is possibly the cause. But if the two formats are incompatible, this should be documented in the Wiki (https://github.com/EventStore/EventStore/wiki/Reading-Streams-%28HTTP%29) with a big exclamation point.

Other point: If not using "embed", how do I efficiently read all events of a stream? One example is a "replay" operation for a view. Hundreds of HTTP requests for reading the content of single events wouldn't be very efficient.

@ouro-ouroboros

This comment has been minimized.

Show comment Hide comment
@ouro-ouroboros

ouro-ouroboros Jan 4, 2014

Contributor

It’s pretty efficient if they’re all being served from a cache.

Contributor

ouro-ouroboros commented Jan 4, 2014

It’s pretty efficient if they’re all being served from a cache.

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Jan 5, 2014

Owner

Are you using http 1.1? It supports pipelining and all events assuming not secure are infinitely cacheable as such in replay they come from an intermediary...this is a common misconception with the protocol it seems at first glance terribly inefficient but is at scale rather reasonable.

Greg

Sent from my iPhone

On 04 Jan 2014, at 16:00, Michael Schnell notifications@github.com wrote:

Yes, breaking the ATOM schema is possibly the cause. But if the two formats are incompatible, this should be documented in the Wiki (https://github.com/EventStore/EventStore/wiki/Reading-Streams-%28HTTP%29) with a big exclamation point.

Other point: If not using "embed", how do I efficiently read all events of a stream? One example is a "replay" operation for a view. Hundreds of HTTP requests for reading the content of single events wouldn't be very efficient.


Reply to this email directly or view it on GitHub.

Owner

gregoryyoung commented Jan 5, 2014

Are you using http 1.1? It supports pipelining and all events assuming not secure are infinitely cacheable as such in replay they come from an intermediary...this is a common misconception with the protocol it seems at first glance terribly inefficient but is at scale rather reasonable.

Greg

Sent from my iPhone

On 04 Jan 2014, at 16:00, Michael Schnell notifications@github.com wrote:

Yes, breaking the ATOM schema is possibly the cause. But if the two formats are incompatible, this should be documented in the Wiki (https://github.com/EventStore/EventStore/wiki/Reading-Streams-%28HTTP%29) with a big exclamation point.

Other point: If not using "embed", how do I efficiently read all events of a stream? One example is a "replay" operation for a view. Hundreds of HTTP requests for reading the content of single events wouldn't be very efficient.


Reply to this email directly or view it on GitHub.

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Mar 17, 2014

Owner

I will look at this tomorrow as we have a release coming.

Owner

gregoryyoung commented Mar 17, 2014

I will look at this tomorrow as we have a release coming.

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Apr 21, 2014

Owner

@jen20 do we want to visit this before 3.0? or just chalk it up to protocol compat?

Owner

gregoryyoung commented Apr 21, 2014

@jen20 do we want to visit this before 3.0? or just chalk it up to protocol compat?

@michael-schnell

This comment has been minimized.

Show comment Hide comment
@michael-schnell

michael-schnell Apr 21, 2014

Would be nice if it gets fixed :-) In Java you can easily switch from JSON to XML or any other serializer that supports JAXB just by configuration. At the moment this does not work because the above difference.

Would be nice if it gets fixed :-) In Java you can easily switch from JSON to XML or any other serializer that supports JAXB just by configuration. At the moment this does not work because the above difference.

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Apr 21, 2014

Owner

Its also not atom compliant :)

On Mon, Apr 21, 2014 at 7:25 PM, Michael Schnell
notifications@github.comwrote:

Would be nice if it gets fixed :-) In Java you can easily switch from JSON
to XML or any other serializer that supports JAXB just by configuration. At
the moment this does not work because the aboce difference.


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-40948988
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

Owner

gregoryyoung commented Apr 21, 2014

Its also not atom compliant :)

On Mon, Apr 21, 2014 at 7:25 PM, Michael Schnell
notifications@github.comwrote:

Would be nice if it gets fixed :-) In Java you can easily switch from JSON
to XML or any other serializer that supports JAXB just by configuration. At
the moment this does not work because the aboce difference.


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-40948988
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

@michael-schnell

This comment has been minimized.

Show comment Hide comment
@michael-schnell

michael-schnell Apr 21, 2014

JAXB? Of course, It does not say anything about the content. It just describes the way how serialization is done. So if the XSD correctly describes the atom format it should work out of the box.

JAXB? Of course, It does not say anything about the content. It just describes the way how serialization is done. So if the XSD correctly describes the atom format it should work out of the box.

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Apr 21, 2014

Owner

I mean that putting that stuff in the atomfeed is not compiant with the
atom protocol :)

On Mon, Apr 21, 2014 at 7:30 PM, Michael Schnell
notifications@github.comwrote:

JAXB? Of course, It does not say anything about the content. It just
describes the way how serialization is done. So if the XSD correctly
describes the atom format it should work out of the box.


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-40949479
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

Owner

gregoryyoung commented Apr 21, 2014

I mean that putting that stuff in the atomfeed is not compiant with the
atom protocol :)

On Mon, Apr 21, 2014 at 7:30 PM, Michael Schnell
notifications@github.comwrote:

JAXB? Of course, It does not say anything about the content. It just
describes the way how serialization is done. So if the XSD correctly
describes the atom format it should work out of the box.


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-40949479
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

@michael-schnell

This comment has been minimized.

Show comment Hide comment
@michael-schnell

michael-schnell Apr 21, 2014

Yepp :-)

Yepp :-)

@gregoryyoung

This comment has been minimized.

Show comment Hide comment
@gregoryyoung

gregoryyoung Apr 21, 2014

Owner

I guess I could see the validity of it being there if application/xml or
text/xml but not in the actual atom feed.

@jen20 this seems like a reasonable middle ground. What are your thoughts?

On Mon, Apr 21, 2014 at 7:33 PM, Michael Schnell
notifications@github.comwrote:

Yepp :-)


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-40949800
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

Owner

gregoryyoung commented Apr 21, 2014

I guess I could see the validity of it being there if application/xml or
text/xml but not in the actual atom feed.

@jen20 this seems like a reasonable middle ground. What are your thoughts?

On Mon, Apr 21, 2014 at 7:33 PM, Michael Schnell
notifications@github.comwrote:

Yepp :-)


Reply to this email directly or view it on GitHubhttps://github.com/EventStore/EventStore/issues/83#issuecomment-40949800
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

@jen20

This comment has been minimized.

Show comment Hide comment
@jen20

jen20 Aug 19, 2014

Owner

We should consider documenting the difference, but I'm not sure adding content embedding into atom+xml is necessarily a good idea.

Owner

jen20 commented Aug 19, 2014

We should consider documenting the difference, but I'm not sure adding content embedding into atom+xml is necessarily a good idea.

@jen20 jen20 added the documentation label Aug 19, 2014

@jen20 jen20 added this to the v3.0.0 milestone Aug 19, 2014

@jen20

This comment has been minimized.

Show comment Hide comment
@jen20

jen20 Sep 7, 2014

Owner

I've added a note to the wiki documentation about embedding being supported only with JSON. The new documentation will make this more obvious.

Owner

jen20 commented Sep 7, 2014

I've added a note to the wiki documentation about embedding being supported only with JSON. The new documentation will make this more obvious.

@jen20 jen20 closed this Sep 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment