I have been looking at how to bring in the competing consumers http
api as well as possible support SSE for live feeds of streams over
http. This brings up a bit of an issue in terms of how to structure
the uris for this. I briefly discuss some of it here
So what I am looking at doing (this will be in the version after
3.1.0) is the following.
/streams/foo will BY DEFAULT return a description document.
/streams/foo Accept: vnd.eventstore.stream_desc will return a
/streams/foo Accept: application/atom+xml will return an XML atom feed
/streams/foo Accept: application/atom+json will return a json atom feed
^^ you get the idea.
The reasoning for this is to allow many stream representations in a
sane uri hierarchy that is also discoverable.
I have spent a long time looking at this and so far only see one place
where this would be a breaking change. The place is if you are
currently getting atom feeds and NOT setting an accept header as it
changes the default.
Would anyone have any major issues with this change? For me it makes a
quite nice, sane, extensible mechanism for being able to extend to
methods of reading streams without doing client side bookmarking