# Dealing with a “there can only be one” attribute **URL:** \ **Category:** Uncategorized\ **Created:** [March 18, 2016, 4:44pm UTC](https://discuss.jsonapi.org/t/dealing-with-a-there-can-only-be-one-attribute/396 "2016-03-18T16:44:40Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![cherewaty](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/cherewaty/32/242_2.png) [@cherewaty](https://discuss.jsonapi.org/u/cherewaty)\ **Post date:** [March 18, 2016, 4:44pm UTC](https://discuss.jsonapi.org/t/dealing-with-a-there-can-only-be-one-attribute/396/1 "2016-03-18T16:44:40Z")
Hi! I’ve got a resource of type `payment-method` with attribute `default`. If I `PATCH` a payment method to be `default: true`, then all other payment methods that belong to that `user` become `default: false`. There can only be one default payment method per user. I’m struggling with the response from that `PATCH`. Do I only respond with the specific record I requested to change, or do I return all of the affected payment methods? Responding with only the specific record `PATCH`ed seems logical, but then consumers of the API have to know that piece of business logic. Right now the app that uses this endpoint just does a `GET` for all of the user’s payment methods immediately after `PATCH`ing any of them. ---
**Author:** ![speterson14](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/speterson14/32/255_2.png) [@speterson14](https://discuss.jsonapi.org/u/speterson14)\ **Post date:** [March 18, 2016, 6:21pm UTC](https://discuss.jsonapi.org/t/dealing-with-a-there-can-only-be-one-attribute/396/2 "2016-03-18T18:21:13Z")
I’m dealing with the exact same problem and would also love some advice. Someone else on my team suggested changing my API so that the equivalent to your user resource has a default\_payment\_method relationship. You would then update a payment method to be the default by updating the relationship on the user resource to point to that payment method. The backend logic and way that you store payment methods could remain the same in terms of having a default: true on the payment methods, but the API could just expose it differently so that implicit “there can only be one” logic would be clearer to clients. However, I’m not sure whether this is the best way to go or not, or whether it works for your use case. ---
**Author:** ![yves](https://avatars.discourse-cdn.com/v4/letter/y/9e8a1a/32.png) [@yves](https://discuss.jsonapi.org/u/yves)\ **Post date:** [April 3, 2016, 11:15am UTC](https://discuss.jsonapi.org/t/dealing-with-a-there-can-only-be-one-attribute/396/3 "2016-04-03T11:15:56Z")
If we stick to the specification : > If a server accepts an update but also changes the resource(s) in ways other > than those specified by the request (for example, updating the updated-at > attribute or a computed sha), it MUST return a 200 OK response. The > response document **MUST include a representation of the updated** > **resource(s) as if a GET request was made** to the request URL. You should return the same result for your `PATCH` than for the `GET` on this resource, so you can’t return all the affected payment methods (except if they can be in the included maybe ?). I like the suggestion of @speterson14 to explicitly give the default payment method in a user relationship. In this case, you could change the default payment method by PATCHing the relationship and not the payment-method resource. If we take the consumer point of view, I think this `default` attribute is more a type of relationship between the `user` and the payment method than a property owned by the payment method. ---
**Author:** ![cherewaty](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/cherewaty/32/242_2.png) [@cherewaty](https://discuss.jsonapi.org/u/cherewaty)\ **Post date:** [April 4, 2016, 6:53pm UTC](https://discuss.jsonapi.org/t/dealing-with-a-there-can-only-be-one-attribute/396/4 "2016-04-04T18:53:18Z")
@speterson14 we successfully used your suggestion to make a relationship between the user and the default payment method. That fit exactly what we needed to do, while staying within the bounds of the spec @yves mentioned. Thanks y’all!