Return all User activity in API users/:uid/activity

[aaronschachter]

Makes nid parameter optional. If not specified, endpoint returns all User Activity for the given uid.

Closes #4230

GET http://dev.dosomething.org:8888/api/v1/users/current/activity.json

[
  {
    sid: "1619",
    nid: "1280",
    signed_up: "1426632905",
    source: null,
    rbid: null
  },
  {
    sid: "1610",
    nid: "1334",
    signed_up: "1426203286",
    source: "SlothieBoy Example",
    rbid: "1200",
    created: "1426204374",
    updated: "1426204374",
    quantity: "123",
    why_participated: "Please work",
    num_participants: null,
    flagged: "0",
    flagged_reason: null,
    fids: [
      "2606"
    ],
    node_title: "Can-Tribute",
    noun: "items",
    verb: "donated",
    quantity_label: "items donated"
  }
]

GET http://dev.dosomething.org:8888/api/v1/users/current/activity.json?nid=1334

{
  sid: "1619",
  nid: "1280",
  signed_up: "1426632905",
  source: null,
  rbid: null
}

[angaither]

Code looks ok, but questions...
During the api meeting with @weerd, didn't we decide to remove drupal specific IDs, to make the api more framework agnostic?
https://gist.github.com/weerd/40328cb6205c2de82db4#comment-1411792

[weerd]

Yep yep. We had agreed on not using names as nid, uid, fid, etc, but namespacing them in own object in JSON. We want people like Joe Flatiron to know pretty quickly what an id applies to and not be confused by what nid means.

[aaronschachter]

TLDR I think it makes sense to have a little more of a game plan before we start refactoring the Drupal API of WHERE our API will/should actually be built.

I can change this endpoint in particular to match just regular id properties and also nested properties, but there are a few apps that use the Drupal API in its current Drupally format that would prevent us from making these changes across the board.

• Campaign gallery
• Email digest things
• Realtime app
• Reviewer iOS app

Where the source campaign activity is stored (Drupal or Northstar) has been coming up in recent conversations i've been having with @jonuy as we're trying to spec out where and how to build required functionality for the mobile app.

[aaronschachter]

The reason I can change this endpoint in particular without any breakage is that isn't used by any of those apps, and only by the SlothKit iOS API wrapper for now.

[weerd]

Gotcha. That makes sense.

I think that since this endpoint won't cause breakage then it should definitely be updated to follow in line with what we decided at the meeting. We already know we need to update those other endpoints and take care doing it since some services are relying on them at the moment. But if this is an untouched endpoint right now then definitely go with new approach; one less to have to refactor later on.

[aaronschachter]

Yeah, plus it will provide some base object wrappers to use in the others as we refactor. it's just, you know, more work :)

I'm debating whether or not this endpoint should be renamed from users/:uid/activity to users/:uid/campaigns, and we can pass various parameters such as status=doing or status=completed as well as filtering by a nid or tid. ugh but then even then, that's too drupally. i think for now I'lll just refactor the output and save the params for a diff day (esp if we end up ditching Drupal services for this stuff)

[weerd]

Yeah, I think that sounds good. At least if we end up changing the end of the endpoint, the code will still apply, it just points to a different spot, etc. So not all is lost!

Anyhoo, defs more work, but it'll pay off in the end with a more usable API!

[aaronschachter]

I think this needs further specification before I can really begin to tackle this, esp re: nesting different entieis per @DFurnes and @angaither comments in https://gist.github.com/weerd/40328cb6205c2de82db4#comment-1411792 and

I'd like to propose we merge this as is now to unblock prototyping, and can begin developing a proper API once end results are completely specified. Potentially with a different API version to avoid breakage

cc @weerd @angaither @jonuy

[angaither]

that works, I like the idea of v2 using the nested entities.
👍

[aaronschachter]

Sweet! will merge. Just as a heads up, another PR will be coming to handle the functionality we need in #4238, which will also stick to just returning the Signup entities as is.