Does someone really use HTTP/ATOM interface?

Hi all,

I just started playing around with the HTTP/ATOM interface.

My first “GET” ended immediately with an error - The response couldn’t even get parsed because the “Content-Type” header looks like it’s not compliant with the HTTP specification (See

Another rproblem is, that many parameters are only documented by being mentioned somewhere in an example. It looks like there also isn’t any XSD like schema that describes in detail what standard attributes (“eventType”, “data”, “metadata”) or structures are available. How do those parameters relate to standard ATOM stuff like “author”, “title” or “id”?

Looking at the questions in this group, I get the impression that most developers actually only use the C# interface instead of HTTP.

So my question: Does someone really use HTTP/ATOM? Is there any formal description available I missed?

I’d appreciate any help.



What accept header/uri are you using to get event type data and metadata? You can certainly get everything as normal atom feeds with author/title/Id etc. see outputs of curl here for example Re content type we have not had an atom client complain about it before will check the relevant rfcs.

Hi Greg,

What I was looking for is a more detailed description of the meaning of the attributes in the context of the event store.

Let’s take for example the “entry”. It has standard ATOM attributes like “title”, “author” or “summary”. But they have a special meaning in the context of the event store.

From the examples I guess the following:

  • “summary” is just a copy of the “event-type” attribute (What is it good for?)

  • “author” is always (?) “EventStore” - Can I use this field for adding the username?

  • “title” looks like something as “eventNumber@streamId”

But this is only a guess. It would be nice to have some kind of documentation that formally describes all that stuff. For example how many additional (non “atom:common”) attributes like “eventType” are defined and what’s their exact meaning?



You mean when using embed= etc this are non atom compliant fields.

As for author I agree it’s stupid and should be removed. I also think the edit link should be removed as the data is immutable alas many of these things are required in atom (even if stupid in the use case). That said it might be useful to change author to the author of the event. That has not been changed since security has been added.

Is there any documentation of the TCP interface available?

The Scala JVM part is really big (10 MB including the dependencies) and I guess some native Java code will be much smaller.

It would be much smaller however the code would be very nasty. The native client is fully async message passing. Can you describe your use case?


I’m currently investigating if it’s possible to use the event store in the Java Enterprise sector. The problem is that you will have to convince the customers to use a product that is not well known and it’s very different from their standard relational DB installations. I think you can also get many of the benefits the event store provides by using an already existing DB infrastructure. So in my opinion one of the main unique features of the event store is performance. I doubt it’s HTTP performance can compete with an optimized relational database used as a kind of event store replacement. So having a fast and easy to use native (TCP) interface in Java is crucial if we want to have a chance to sell it to our customers.



From research with neventstore in the .net space a single three node cluster (about 1200$ servers single u with reasonable proc, ssd, and 8gb ram) with a load balancer in front (clients do not understand cluster) was hitting about 10000 writes per second and saturating gigabit for reads over the atom interface. This blew away any other provider. Have you benchmarked at all? What benchmarks have you tried?



Hi Greg,

no, I haven’t benchmarked yet. Was the 10000 writes per second really done using HTTP? I think it would be a good idea to have your benchmarks published (if possible including the data used for the test setup) and compared a with similar relational DB setup. I guess this would help a lot selling the event store.



Yes that was over http you can naively hit 20-30k/second over the client API. We have considered publishing such benchmarks with reproducible puppet/chef/docker/etc scripts. We will revisit that discussion.



Cool. Some nice colored charts comparing the traditional relational DB performance to the Event Store would be a big plus.

Hi Michael,

JVM client is based on Akka actors ( and takes a lot of benefit from it’s async IO. But this is a Scala world with scala-library-2.10.3.jar - around 7mb

There is no docs on tcp, except source code:



The problem with idiomatic java code is that everything is async and java causes a huge amount of “boiler plate” code in comparison

Hey Greg,

I think it would be really useful to have the username of the event author in the author field.

For example: if I don’t want to use ACLs for whatever reason, the username would enable subscribers to decide if an event should be processed or not.