Make API responses consistent

[sethvincent]

There are a few examples of inconsistent api responses.

We should do a look through and see if there are other similar inconsistencies, make a list here, and try to update them all at once. These could later be broken into separate issues if needed.

List:

• /api/teams 200 get response is an array of objects, while /api/clients 200 get response is an object with a clients property which is an array of objects
• user OSM id should always be named the same thing and be either a string or an integer. for instance, in the individual team response in the member array the id is a string and represents the osm id but in the moderator array both id and osm_id exist and both are integers
• catch errors in route handlers and provide specific, readable errors instead of whatever the db or other dependency is throwing, for example instead of "insert into \"team\" (\"bio\", \"hashtag\", \"name\") values ($1, $2, $3) returning *, ST_asGeoJSON(\"location\") as \"location\" - duplicate key value violates unique constraint \"team_hashtag_unique\"" we should say something more clear like The hashtag `hashtagname` is already taken. (obvs hashtag will be replaced by tags but this is just an example)

[vgeorge]

In addition to the above, I believe all API responses should return a JSON object on success and error for consistency. There is a number of endpoints returning just a string "OK".

[vgeorge]

Tagging this as a high priority bug, most endpoints are returning the db query as described above. The API must return a message that doesn't expose the queries.