Not following this too closely, but CQRS and event sourcing is an incredibly powerful combination (particularly if you throw DDD in there as well) and might be a perfect fit here... > On 14 Oct 2015, at 04:48, James Reeves <ja...@booleanknot.com> wrote: > > On 13 October 2015 at 09:49, Patrick Kristiansen <patr...@patrkris.dk > <mailto:patr...@patrkris.dk>> wrote: > Has anyone read and given any thoughts to the ideas about immutability and > REST by Ted Dizuba here: > > http://teddziuba.github.io/2014/08/18/the-s-in-rest/ > <http://teddziuba.github.io/2014/08/18/the-s-in-rest/> > > Has anyone done anything resembling this? I think the ideas sounds intriguing. > > It's a reasonable start, but I don't think it goes far enough. Why make only > small parts of a system immutable? Why tie the canonical identifier for an > immutable value to a domain? > > I'd be inclined to model the entire system as a reference. So we have > something that deferences it, producing an immutable snapshot at a certain > point in time, and we have something that atomically updates it. > > For example, we could build a route that gives us an immutable snapshot of > the system, identified by a cryptographic hash. We could also supply a > hypertext reference in the response, which would function as a suggested > source for the snapshot. > > GET https://api.example.com/ <https://api.example.com/> > => {:id #sha1 "aaa", :href #url "https://api.example.com/aaa > <https://api.example.com/aaa>"} > > Once we have the snapshot, we can query it. The simplest way would be via a > subpath: > > GET https://api.example.com/aaa/users <https://api.example.com/aaa/users> > => [{:id #sha1 "bbb", :name "Alice", :job-title "Cryptographer"}] > > But we could conceive of more complex queries as well, ones that would enable > us to fetch multiple parts of the database simultaneously. > > For updating the data, we need a route that accepts some data that represents > how the data is to be changed. So at its most basic, something like: > > POST https://api.example.com/ <https://api.example.com/> > [[:set #sha1 "bbb" :job-title "Senior Cryptographer"]] > > Of course, the difficulty with this architecture is that few databases have > fast, immutable snapshots built in, so you'd have to get a little creative > with your database design. > > - James > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > <http://groups.google.com/group/clojure?hl=en> > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>.
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
