Support client and server generation of a GET endpoint with no parameters

[sleexyz]

Closes #2

TODO:

• [x] add a fragment

[astampoulis]

@sleexyz Pushed a commit, I think it worked out nicely, but please feel free to revert if you disagree!

[sleexyz]

@astampoulis the issue with the flipping the direction is that you end up precomposing the server and client middleware with respect to the order in which the linked list is built. i.e. if you want to extend an endpoint, ur forced to precompose (as opposed to postcompose like before) I'm thinking its alot more natural to postcompose than to precompose.

[astampoulis]

I'm not sure if I get that, could we discuss when you get in?

[astampoulis]

For example, the way I understand this, this direction allows us to do: Cons(middleware: Fragment("/api"), next: Cons(middleware: Fragment("/hello"), next: Nil())) and that would lead to a /api/hello endpoint, which looks more natural than the flipped order. I haven't thought this through with respect to input params etc. though, so I'm probably missing something!

[astampoulis]

Just to complete the discussion above: we talked offline with Sean and figured out that we want to use Snoc lists instead of normal Cons lists -- SnocList a = Nil | Snoc (SnocList a) a instead of List a = Nil | Cons a (List a) --. Reason for Snoc lists is because the common operation is to add stuff to the "end" of an endpoint, as opposed to adding stuff on the top. So if we got a base API route of base: Endpoint = /api/v1, we can do snoc(base, "/users").

Also, in terms of the base URL, we decided that it's better to make that an explicit parameter of the client-side fetch code, since that's the only case where it's needed (and it's needed anyway).

[MatteoVH]

LOL, did you two make up Snoc or is it an established term already?

[sleexyz]

@MatteoVH it's backwards Cons