Re: Ted Dziuba: The S in REST

[Ted Dziuba]

This idea was never fully baked, mostly just thinking out loud.

I did have a system that needed that kind of consistency, and I ended up 
using Datomic. It offers the same consistency and caching, but with a 
robust query language as well.


Ted

On Tuesday, October 13, 2015 at 1:49:26 AM UTC-7, Patrick Kristiansen wrote:
>
> Hi everyone
>
> 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/
>
> Has anyone done anything resembling this? I think the ideas sounds 
> intriguing.
>
> Best regards,
> Patrick
>

-- 
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.

Re: Ted Dziuba: The S in REST

[Bobby Calderwood]

Shameless (but very relevant) plug: come check out my talk at Clojure/conj! 
http://clojure-conj.org/speakers#bcalderwood

On Wednesday, October 14, 2015 at 7:25:35 AM UTC-4, Patrick Kristiansen 
wrote:
>
> On Wednesday, October 14, 2015 at 5:49:06 AM UTC+2, James Reeves wrote:
>>
>> 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.
>>
>
> Which, I guess, is where Datomic would fit in perfectly :-)
>

-- 
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.

Re: Ted Dziuba: The S in REST

[Patrick Kristiansen]

On Wednesday, October 14, 2015 at 5:49:06 AM UTC+2, James Reeves wrote:
>
> 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.
>

Which, I guess, is where Datomic would fit in perfectly :-)

-- 
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.

Re: Ted Dziuba: The S in REST

[Colin Yates]

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  wrote:
> 
> On 13 October 2015 at 09:49, Patrick Kristiansen  > 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/ 
> 
> 
> 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/ 
>   => {:id #sha1 "aaa", :href #url "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 
>   => [{: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/ 
>   [[: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 
> 
> --- 
> 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 
> .

-- 
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.

Re: Ted Dziuba: The S in REST

[James Reeves]

On 13 October 2015 at 09:49, Patrick Kristiansen 
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/
>
> 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/
  => {:id #sha1 "aaa", :href #url "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
  => [{: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/
  [[: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
--- 
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.

Re: Ted Dziuba: The S in REST

[Raoul Duke]

The thought that came to my mind when reading it was something like,
"Hasn't anybody heard of MVCC?"

-- 
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.

Ted Dziuba: The S in REST

[Patrick Kristiansen]

Hi everyone

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/

Has anyone done anything resembling this? I think the ideas sounds 
intriguing.

Best regards,
Patrick

-- 
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.