[backend] API update discussion

[hackertron]

discussion points

• we should we should switch to referring to what is Url now as "content" since it has more descriptive data like title and submittedBy.
  content.link seems more semantic than url.link
• we'll also need a mixer on the frontend to shuffle the content or better yet replace my proposed /links-by-tag with a /mix that's returns a mixed list of content links based on tags passed to it:
  /mix?tags=628983903892&tags=72982772896&tags=628829988261&tags=668827626728829927

Jay points

I understand the points.
calling /mix is fine , under the hood it can call getUrlByTags

randomizing

• tbh I don't expect that we will have millions of urls, thus it made sense to me that random url selection can be done on client side. it's not heavy task .

• we can do that on backend side too but then on frontend , frontend have to just iterate over the response (json that is returned )

• this brings me another question , what if we iterate over complete response, should we just restart the iteration over response again ?
  Currently , it's random access like [1,2,3,4] and select random (arr) . so there is repetition . Many times it can show 2,2 . it's possible.

calling url , content.
-We can do but then we are changing specs completely : https://github.com/State-Channel-4/api-spec. most of my url routes and naming comes from the api-spec.

potential changes

changes that I understand from discussion
using /mix for discover that returns a json response with url and it's associated ID.
calling url to content
random on backend side.

[hackertron]

@NicoSerranoP @thebeyondr

[NicoSerranoP]

I support Jeo in mixing the content (urls) in the backend because: it's just that the more I thought about it the more it seemed like that handler only does 1/2 it's job... the client that calls it will never need structured content.

A /url/mix route could return randomized data and a /url/all could return ordered data

[hackertron]

Understood :)