Backend: REST API

[bzz]

basics

• prepare skeleton with handlers returning http.StatusNotImplemented
• handle GitHub authorization
• implement handlers, returning mocked data
• using DB stuff Backend: DB code #41
• connect front with api Connect the frontend UI with the backend API #56
• end2end tests for the API ??

nice to have

• log 500 error Logg original errors #50
• restrict access of unknown users Restrict access of authenticated users #48

[smacker]

GET /experiments/:id
{
  data: {
    id: <id>,
    name: TEXT,
    description: TEXT
  }
}

GET /experiments/:id/assignments
{
  // should we filter only by assignments with answer? if so we need to return total
  // somewhere and what to do with id? actually for simplicity I would return everything.
  // 1k isn't that much.
  data: [{id, pairId, experimentId, answer, duration}, ...]
}

answer: Yes, No, Maybe, Skip

PUT /experiments/:id/assignments/:id
{
  answer,
  duration,
}

GET /experiments/:id/filePairs/:id
{
  data: {
    id,
    diff
  }
}

[dpordomingo]

Some considerations:
(@bzz tell me if we should somehow persist this in the DesignDocument)

auth:

Auth with Github, auth communication between front and back using JWT and dgrijalva/jwt-go

experiments listing:

GET /experiments/:id/assignments

• experimentId wont be sent
• it will return the assignments for the user identified by the HEADER user token
• it will create all user assignments when it is requested for the first time

Since all assignments are sent at once to the front, all metrics and aggregations will be done in the browser.

sending answers:

The browser will send to the backend the answers whenever it wants (it can be onAnswer, onNext, onClose, onFinish, async...).

When it is sent an assignment, the backend will override the stored one with the data sent, so the frontend will consider if the duration is reset, or added to the previous one.

The frontend will take care of race conditions, many tabs sending the same answer or sending it from the same tab many times in a short period of time.

If @smacker wants, the "save" event could be done "all at once", with, for example:

PUT /experiments/:id/assignments
[{
  id,
  answer,
  duration,
},...]

errors:

The backend will expose the errors as an array of error objects under the errors key.

type ErrorObject struct {
  status int
  title string
  detail string //optional
}

[bzz]

@dpordomingo seems like #37 is ready to be merged! 🎉

If possible, I would prefer merging it, closing this one and opening a new issue for further work on REST API if needed.

[bzz]

removing from "Code review" as #37 seems to be ready for merge

[dpordomingo]

I updated the issue description with the work I think it should be needed to complete the backend and a couple of nice to have.

[bzz]

Very nice, thank you!

I have a feeling that it becomes an umbrella issue without clear reason - i.e cutting a release and tracking its immediate scope is a good reason to have umbrella.

Do you think we could close this one at some point at very close future, as we have REST API already, and keep progress of each sub-task in it's own issue?