Simple relationship question - wishlisting products

[telemetrik]

Hi there folks,

We're in the beginning of decoupling our big, monolith application and I've decided to try with our wishlist service first.

I've searched google and couldn't find any info on this matter, so please point me to some reference, maybe I'm missing something, if so - sorry about that.

Anyways:

In our domain, a user can wishlist an item.

1) How should I model that?

POST /api/wishlisted_items

or

POST /api/users/{userId}/wishlisted_items

2) How should POST payload look like? 

- Should it have a distinct UUID for userId & product pair? Seems like userId + productId are natural composite key for this? 

- If so, how do I represent this id in GET action? Should I?

[telemetrik]

To put a little bit more context on it:

- Wishlist has to have an owner, that's why  /api/users/{userId}/wishlisted_items seems viable to me.

- I'm asking about distinct UUID for a reason - it's super easy for client to DELETE /api/users/{userId}/wishlisted_products/{productId}, but to DELETE /api/wishlisted_products/{id}, I'd have to store that information on somewhere the client side.

I'm really trying to wrap my head around it.

[Kijana Woodard]

I like the second one personally.

Do wish list items become independent resources? 

Is there any wish list context specific information for each item?

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[telemetrik]

Hey Kijana!

Glad to see you here as well. ;)

Do wish list items become independent resources? 

 

Is there any wish list context specific information for each item?

For now it's just a pair of product and user relation and (optionally) UUID:

so GET /api/users/{userId}/wishlisted_items

  [{

    "id": "863790b1-df0d-11e5-9e2e-0242ac110004",

    "_links": {

      "user": {

        "href": "http://user/1'"

      },

      "product": {

        "href": "http://product/2'"

      }

    }

  }]

Regards

[telemetrik]

Anyone? :)

On Monday, February 29, 2016 at 6:41:45 PM UTC+1, telemetrik wrote:

[Mei Misaki]

Hi telemetrik,

I suggest forgo words 'items'. 

I propose such REST API:

POST .../users/{userId}/wishlisted/

[

  { "productId": "6"}, 

  { "productId": "42"}

]

GET .../users/{userId}/wishlisted/

  [{

  "id": "863790b1-df0d-11e5-9e2e-0242ac110004",

  "_links": {

  "user": {

  "href": "http://user/1'"

  },

  "products": [{

  "product": {

  "href": "http://product/6'"

  },

  "product": {

  "href": "http://product/42'"

  }

  }]

  }

  }]

DELETE .../users/{userId}/wishlisted/{productId}

 

BR,

Mei

[telemetrik]

Now what if I want to include datetime when specific product was wishlisted?

[Andrew B]

Just to address part of your question:

When posting the wishlisted items, you have choices depending on how the API call is authorized.

If e.g. it is via an Oauth token that contains or implies the user's identity, then you can make your API like this:

POST /api/wishlistedItems

No need to pass user in the URL, instead the back end extracts it from the oAuth token. (In house we call these "on behalf" APIs). Nice from a security perspective, as authorized users can only adjust their own wishlisted items.

However perhaps you also need the capability for people to adjust others wishlisted items? In that case you add a second API:

POST /api/wishlistedItems/users/{user}

Assuming you still can extract the user from the OAuth token, your back end now needs to ensure that the oauth token user is "allowed" to adjust the wishlist items of the {user} user. e.g. perhaps the oauth token user is an admin person.

I personally prefer having both these APIs for increased security, assuming you have some kind of framework that allows you to lock down access on a per-API, per-client model (which you should).

For example, let's say you have a client application HACKZOR, built by your well-meaning but inexperienced interns. You love their raw enthusiasm but their gung-ho-ness makes you nervous. So you make sure HACKZOR is only allowed to make calls to the on-behalf API (POST /api/wishlistedItems).

Now lets assume that the interns were indeed sloppy, and their HACKZOR client application is hacked. This is bad - but because you are using on-behalf APIs, it's not catastrophic. That's because HACKZOR can only alter the wishlist items for a user who it has an OAuth token for - and the authorization server only hands those out for people who have actually logged in.

Of course any user who has used HACKZOR since it was hacked is at risk - but, depending on how long the hack went undetected for, that could mean that only hundreds of accounts were compromised, not millions. You extract yourself from the situation by firing an intern or two but you don't make it into the newspaper. Phew.