Possible breaking change in http

EventStoreDB
1

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
https://github.com/EventStore/EventStore/issues/424

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
description document
/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

2

You have the moral high ground to do this.

HTTP spec (v2616, didn’t check bis) specifically says that a client is assumed to accept ALL content types if it doesn’t provide an Accept header. As a bet practice, the Accept header should be considered required for any normal user agent. If a client doesn’t provide the header, it’s playing with fire because the server CAN change the content type on whim.

Heck, some server frameworks return 406 when clients don’t provide an Accept header. I’m a little vague on the legality of this behavior, but it definitely reduces client “sloppy” errors.

So, I support this. It feels like an API improvement that should only break sloppy clients.

-Sam