Atomchanges

These are the changes discussed on the list having to do with posting to atom feeds. I do not believe the req is 100% but it should be fairly close. A summary of the change follows:

Currently our behaviour is to internally treat any json/xml that gets posted as being of the form

[
    { 
      "eventId"    : "string", 
      "eventType"  : "string",
      "data"       : "object",
      "metadata"   : "object"
    }
]

This is not highly compliant with the atom protocol which is the first introduced change and it does not allow for a client that cannot create a uuid to post/make idempotent posts.

The first change is to make content-types such as application/json and text/xml be understood as the body of the post is the actual content to post. This of course begs the question of the event-type and event-id. For this two headers have been added to the system ES-EventType and ES-EventId. This should provide for a more natural http interface to the event store though this is a breaking change as if you want to post with the above schema it would require vnd.eventstore.events+json.

The second large change has to do with the scenario that the client is posting an event as content but is unable to generate a uuid for idempotency purposes. In this case the message interface would not include the ES-EventId header. The system will redirect the caller to a unique uri in the form of streams/{stream}/incoming/{guid} this generated uri contains the uuid in the uri and is made idempotent for the client.