# Post with additional (not supported) attribute **URL:** \ **Category:** Uncategorized\ **Created:** [April 13, 2016, 2:53pm UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429 "2016-04-13T14:53:53Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![lukasoppermann](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/lukasoppermann/32/178_2.png) [@lukasoppermann](https://discuss.jsonapi.org/u/lukasoppermann)\ **Post date:** [April 13, 2016, 2:53pm UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/1 "2016-04-13T14:53:53Z")
Hey, so if I have a `POST` endpoint and I expect the attributes `name` and `age`, but the provided data in the `POST` request is `name`, `age` and `gender`, what is the correct response? Should I just ignore `gender` and create the record, returning the created record (without `gender`). Or do I need to respond with a `403` or something? ---
**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\ **Post date:** [April 13, 2016, 3:36pm UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/2 "2016-04-13T15:36:09Z")
> [@lukasoppermann](#): > > Should I just ignore gender and create the record [Postel’s Law](https://en.wikipedia.org/wiki/Robustness_principle) says yes. You _may_ wish to add something in the `meta` section to provide feedback to the client that you ignored part of their data. ---
**Author:** ![lukasoppermann](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/lukasoppermann/32/178_2.png) [@lukasoppermann](https://discuss.jsonapi.org/u/lukasoppermann)\ **Post date:** [April 13, 2016, 3:50pm UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/3 "2016-04-13T15:50:54Z")
Hmm, definitely an interesting approach. I just wonder if this is also the “official” json api approach. ---
**Author:** ![aah](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/aah/32/238_2.png) [@aah](https://discuss.jsonapi.org/u/aah)\ **Post date:** [April 15, 2016, 12:36am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/4 "2016-04-15T00:36:00Z")
We went back-and-forth on this for our still-in-development API. Our take was to be super strict in validation, on the basis that dangling attributes / what-have-you may be symptoms of some other underlying issue in the client. I appreciate Postel’s law as much as the next guy, and I considered it when designing this API, but some small part of me was thinking “he said that because SMTP was poorly specced and there were already a million clients and he didn’t want to make things worse – we’re a clean slate, we don’t have to be nice.” ---
**Author:** ![dnperfors](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/dnperfors/32/135_2.png) [@dnperfors](https://discuss.jsonapi.org/u/dnperfors)\ **Post date:** [April 18, 2016, 10:27am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/5 "2016-04-18T10:27:51Z")
Of course I can’t give you the “official” answer, but I am currently also implementing the POST in our API and had basically the same question. Since there is no mention of this in the spec, we decided to just ignore the attributes, which is basically in line with the rule that you don’t have to specify all the attributes when creating or updating a resource. ---
**Author:** ![lukasoppermann](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/lukasoppermann/32/178_2.png) [@lukasoppermann](https://discuss.jsonapi.org/u/lukasoppermann)\ **Post date:** [April 18, 2016, 11:05am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/6 "2016-04-18T11:05:06Z")
@aah @dnperfors I can see the benefits in both approaches. Currently I am thinking that the user probably gets the bigger benefit in an explicit error, so he knows that something is wrong. This could save you from issues like submitting a patch request with e.g. `naem` (a typo of `name`) where you do not notice that the `name` field is not updated do to the system ignoring the wrong field. Thanks for both the answers though. ---
**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\ **Post date:** [April 18, 2016, 10:27pm UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/7 "2016-04-18T22:27:56Z")
> [@lukasoppermann](#): > > the user probably gets the bigger benefit in an explicit error, so he knows that something is wrong. That’s definitely useful, and why I suggested perhaps providing feedback using the `meta` section. But if you actually enforce a hard error here then you potentially limit the evolvability of your API - in future if you decided that you no longer needed or wanted the `name` attribute you couldn’t remove it from your API without breaking existing clients. ---
**Author:** ![aah](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/aah/32/238_2.png) [@aah](https://discuss.jsonapi.org/u/aah)\ **Post date:** [April 19, 2016, 2:26am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/8 "2016-04-19T02:26:30Z")
> [@jlangley](#): > > in future if you decided that you no longer needed or wanted the name attribute you couldn’t remove it from your API without breaking existing clients Can you expand on this? I’m having trouble seeing how the issue is related to enforcing hard errors or not. ---
**Author:** ![lukasoppermann](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/lukasoppermann/32/178_2.png) [@lukasoppermann](https://discuss.jsonapi.org/u/lukasoppermann)\ **Post date:** [April 19, 2016, 4:30am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/9 "2016-04-19T04:30:38Z")
Also, don’t you think it is risky to remove attributes and make it seem to not be a breaking change? Of course, you should NOT do it, but if you needed to change `sex` to `gender` and it would not be a required field, ignoring `sex` might actually do more harm in not breaking the API, as the user expects the `sex` attribute to be added, but instead it is just ignored. I would think it is better to bump the version number of your api if you really need to do those things. Adding fields should not be a problem, even with the hard restrictions. ---
**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\ **Post date:** [April 20, 2016, 9:16am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/10 "2016-04-20T09:16:13Z")
> [@aah](#): > > Can you expand on this? I’m having trouble seeing how the issue is related to enforcing hard errors or not. Suppose `name` is a mandatory attribute for a POST, and suppose that the API generates errors when POSTs contain data the API does not support. If the API is changed so that `name` is no longer used by the API you have two options: 1. Make `name` an optional attribute. Old clients will continue to work. New clients might send `name` or they might not, either way will work. 2. Remove `name` from the API. New clients will not send `name` (because they will see an error if they try to do this). Old clients will all start to receive errors for calls that were previously valid 😢 > [@lukasoppermann](#): > > Also, don’t you think it is risky to remove attributes and make it seem to not be a breaking change? In my point of view, removing a previously required attribute should _not_ be a breaking change, so generating errors is the wrong thing to do. I want the API to be evolvable, and I don’t want to break existing clients unless I have to. So I would treat removing **any** attribute (optional or mandatory) as a _non-breaking_ change (because it is easy for the API to ignore unwanted data supplied in the old format from existing clients). > [@lukasoppermann](#): > > Of course, you should NOT do it, but if you needed to change sex to gender and it would not be a required field, ignoring sex might actually do more harm in not breaking the API, as the user expects the sex attribute to be added, but instead it is just ignored. An attribute rename is effectively removing an attribute (`sex`) and adding an attribute (`gender`), they just happen to contain the same data type. Adding the attribute add is a non-breaking change (because the attribute is optional). Whether removing an _optional_ attribute is different from removing a _mandatory_ attribute is an interesting question; but I would prefer to handle the change in the same way (as described above). ---
**Author:** ![lukasoppermann](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/lukasoppermann/32/178_2.png) [@lukasoppermann](https://discuss.jsonapi.org/u/lukasoppermann)\ **Post date:** [April 20, 2016, 9:34am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/11 "2016-04-20T09:34:56Z")
Your arguments seem valid to me and I can totally understand where you are coming from. But the only benefit would be to be able to remove a field without producing errors. - Adding mandatory fields will produce an error in either case. - Adding optional fields will not result in an error in either case. However the downside still exists, that while clients do not break, the intended behaviour might “break”. As in, user will now not be able to change their gender as you renamed the field. Finding where the error lies will be much more complicated, since the API does not throw an error. I think that non-additive changes should always result in a version increase. ---
**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\ **Post date:** [April 20, 2016, 10:06am UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/12 "2016-04-20T10:06:59Z")
> [@lukasoppermann](#): > > However the downside still exists, that while clients do not break, the intended behaviour might “break”. As in, user will now not be able to change their gender as you renamed the field. Yes. In this _particular_ case I would be tempted to make this a breaking change (and return an error if `sex` was sent in a request). But where the only change is the removal of an attribute I would prefer this not to be breaking; and therefore I would prefer (generally) to ignore unexpected data. I think this gives a looser coupling and makes it easier to evolve the API. > [@lukasoppermann](#): > > Finding where the error lies will be much more complicated, since the API does not throw an error. Agreed. That’s why I suggested the possibility of feeding back via `meta` even if no error is generated. This feedback could help track down the reason for the unexpected / broken behaviour. ---
**Author:** ![brainwipe](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/brainwipe/32/209_2.png) [@brainwipe](https://discuss.jsonapi.org/u/brainwipe)\ **Post date:** [April 24, 2016, 10:07pm UTC](https://discuss.jsonapi.org/t/post-with-additional-not-supported-attribute/429/13 "2016-04-24T22:07:18Z")
The discussion is interesting and I agree that the spec doesn’t mention it explicitly. I would argue that how you deal with incomplete resource POST/PUT depends on the level of processing you’re doing with the resource: 1. If you are storing the resource for retrieval and performing no processing; then an incomplete resource is OK. 2. If you are expecting business logic to process the resource, then an incomplete resource is bad. I tend to prefer APIs with clear cut rules and “fail fast”. If I am coding against an API then I want to ensure that I am doing it write and it’s a lot easier if you have a clear definition of what you need to send for a given operation. When serving APIs to others, I need the versioning to be explicit so that the consumers of it can plan and upgrade as required. Breaking API changes are a pain but sorting out incomplete data in the database months after its collected is often impossible.