2017-02-01 22:06:36 +0000 <fuzzyhorns> check out the response examples
2017-02-01 22:06:45 +0000 <fuzzyhorns> under "operations"
2017-02-01 22:07:37 +0000 <fuzzyhorns> so "rel": "on" is what we'd want a client to "trust", whereas they should not "trust" "href": "/toaster" to not change on them whenever
2017-02-01 22:08:24 +0000 <fuzzyhorns> for me this is where servant could be very, very interesting — it's the only thing i've found where i really have input and return types of api endpoints in a "nice" way
2017-02-01 22:08:26 +0000mettekou(~mettekou@94-224-246-64.access.telenet.be)
2017-02-01 22:10:16 +0000 <jkarni> hm
2017-02-01 22:10:50 +0000 <jkarni> dynamic rels are possible, but then we'd definitely need to make things configurable
2017-02-01 22:11:52 +0000 <jkarni> two points in the design space are making it that (at least for APIs that follow certain rules) no other information is required for HATAOS support, or making it completely configurable
2017-02-01 22:11:57 +0000 <jkarni> likely the best option is both
2017-02-01 22:12:28 +0000mettekou(~mettekou@94-224-246-64.access.telenet.be) (Ping timeout: 240 seconds)
2017-02-01 22:12:51 +0000mettekou(~mettekou@46.166.137.235)
2017-02-01 22:12:53 +0000 <jkarni> so how about:
2017-02-01 22:13:57 +0000 <jkarni> by default, the operations/outward links are all children, with rel == suffix, but other rules can be used, and also specific things tweaked?
2017-02-01 22:14:56 +0000 <jkarni> also by default, no 'Expects'
2017-02-01 22:15:15 +0000 <fuzzyhorns> mm, like nested resources in rails, i am more curious about what rels i can provide based on the response type i have
2017-02-01 22:17:57 +0000 <jkarni> maybe one way of designing that is making explicit that certain links take certain state as input
2017-02-01 22:18:15 +0000 <fuzzyhorns> yeah, that is what i am hoping is possible
2017-02-01 22:18:33 +0000 <fuzzyhorns> thanks for humoring my very fuzzy thoughts on this btw
2017-02-01 22:18:34 +0000 <jkarni> definitely is
2017-02-01 22:18:56 +0000 <jkarni> not at all - working through new ideas with people is one of the best parts of programming!
2017-02-01 22:19:02 +0000 <fuzzyhorns> :)
2017-02-01 22:19:18 +0000 <fuzzyhorns> i want to have a servant api output as a state machine graph, like i've been doing in this ruby project: https://mooreniemi.github.io/choclety/
2017-02-01 22:19:32 +0000 <fuzzyhorns> ruby isn't great for this (obviously probably) because you dont have types to help out
2017-02-01 22:20:05 +0000 <fuzzyhorns> my hope is with servant, i can use such a graph representation to give not just a visualization of an api, but metrics about it like how many interactions are necessary to get to such and such a target state
2017-02-01 22:20:56 +0000 <fuzzyhorns> i figure since HasDocs exists, I can write a HasGraph
2017-02-01 22:22:17 +0000 <jkarni> ok, so let's say that we define a new combinator, ExpectsState a
2017-02-01 22:23:07 +0000 <jkarni> or rather, let's give it two params
2017-02-01 22:23:18 +0000 <jkarni> ExpectsState expected endpoint
2017-02-01 22:24:21 +0000 <jkarni> and as an example API, let's consider type API = Get Powered :<|> ReqBody Strength :> Put () (omitting content-types for simplicity)
2017-02-01 22:24:55 +0000 <jkarni> now, the PUT endpoint in fact checks whether thing is Powered (data Powered = On | Off)
2017-02-01 22:25:19 +0000 <jkarni> so with the new combinator, we write:
2017-02-01 22:25:52 +0000 <jkarni> API = Get Powered :<|> ExpectState 'On (Get Powered) :> ReqBody Strength :> Put ()
2017-02-01 22:26:14 +0000 <jkarni> (we need a Reifies instance for Powered)
2017-02-01 22:26:27 +0000 <fuzzyhorns> (i am making a note of this for later)
2017-02-01 22:26:39 +0000 <jkarni> now, the handler for put gets an extra argument, of type Powered