exposing card iin

[bninja]

address #136

[bninja]

@mahmoudimus ready and waiting

[mahmoudimus]

Will get to this when I can

[mahmoudimus]

First issue I see here is that there's an endpoint called IIN that's a sub-resource of the card identifier. Without this endpoint having an identifier, I think this breaks the HATEOAS principle.

[bninja]

@mahmoudimus added the uri for that sub-resource here https://github.com/balanced/balanced-api/pull/286/files#L3R9

[mahmoudimus]

@bninja - I understand that is an index operation, now a show operation. This is the first resource of its kind in our system, so it breaks our consistency.

For example, here's an example:

curl https://api.balancedpayments.com/

Our server responds:

{
  "first_uri": "/?limit=10&offset=0",
  "items": [
    {
      "uri": "/v1"
    }
  ],
  "previous_uri": null,
  "uri": "/?limit=10&offset=0",
  "limit": 10,
  "offset": 0,
  "total": 1,
  "next_uri": null,
  "last_uri": "/?limit=10&offset=0"
}

However, this pagination breaks if we do it on an ``iin_uri`. There's nothing identifying this resource. Essentially, it is not addressable and this breaks HATEOAS.

[quellhorst]

Why not include the IIN information when you retrieve a card?

[bninja]

@quellhorst i was thinking most wouldnt need it so i didn't bother inlining the subresource (client lazy fetches on .iin access).

[quellhorst]

@bninja makes sense, will keep things clean.

[mahmoudimus]

We will not do this right now.