How to tell if an API is bad

a screenshot of the Tableau REST API documentation

Hey look, they highlighted the part I hate:

Note: After creating the user, you must set a full name, password, and email address for the user with the call to Update User.

I have a feature suggestion, perhaps this is daft, but if I must update a user with information via a different call after creating it, I don’t know, maybe I could just provide that information when creating the user?

To be fair, a nice attempt has been made to build the API around resources, which means it’s a REST API! And that is good. But what would have been nicer would have been considering some use-cases. Why are people going to use the API.

My use case: When a new user comes in, create a Tableau user in a specific group. If the user already exists in Tableau then update with the latest data.

This requires the following API calls:

  1. Sign-in, because the API is secured with a token but you need to get this from a username-password combo…
  2. Check the user exists on the site
  3. Create the user against the site if they don’t exist
  4. Update the user
  5. Create the user against the group (we can let this fail if they are already in the group because we don’t need anything from the result of this call)

Maybe GraphQL will save us all?

my favourite javascript framework is javascript

Sometimes to say that you “wrote” a piece of code feels wrong, it can feel more like you discovered it. Or re-discovered it anyhow, because it probably exists in many other places in slight variations.

function h (tag, attrs = {}, children = []) {
  const el = document.createElement(tag)

  for (const attr in attrs) {
    if (attr.startsWith('on')) {
      el[attr] = e => attrs[attr](el, e)
    } else {
      el.setAttribute(attr, attrs[attr])
    }
  }

  for (const child of children) {
    if (typeof child === 'string') {
      el.appendChild(document.createTextNode(child))
    } else {
      el.appendChild(child)
    }
  }

  return el
}

Which I wrote while updating alexandria as,

It captures what I like about Elm, but in a slightly uglier way.

h('input', {
  class: 'title',
  value: data.title,
  onblur: me => this.setTitle(me.value),
  onkeypress: (me, e) => {
    if (e.keyCode === 13) me.blur()
  }
})

Of course I’m not saying anyone should go out and use this as the core idea of their applications, especially if writing as part of a team. Using something with a bit more structure is obviously needed to prevent large apps becoming soup; this is a 300ish line app that essentially draws a <table>. And I’m pretty sure rebuilding rows when filtering or sorting isn’t the most efficient way of programming against the DOM, though I doubt it is too bad for the size of table I have.

What I’m trying to say is, with all of us only using frameworks we can sometimes forget how nice plain ol’ JavaScript is in the year 2019.

Pretty cool that Jamie is going to be starting a Homebrew Website Club in Nottingham. I will be there.

a picture of a can

I just wanted to share a picture of this can. Isn’t it great? I guess it still doesn’t beat a kwak.