Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misleading message: "Key is not included in URL" #785

Open
markusbuschhoff opened this issue Jul 28, 2016 · 1 comment
Open

Misleading message: "Key is not included in URL" #785

markusbuschhoff opened this issue Jul 28, 2016 · 1 comment

Comments

@markusbuschhoff
Copy link

Great gem, but the error message "Key is not included in URL" seems misleading to me for some reasons.

I) It is not clear whar is meant by "key" (I would suggest "id").
II) The message references a concrete problem in the URL, a missing key, which might not be true (e.g. a wrong key might be the problem as well).
III) The error could have happened in the data section as well.
IV) This message is returned whenever something goes wrong with the id (e.g. wrong type of id field in the data section), see example

Example: The following patch request to the correct url (and id) might cause this error message due to an invalid data type (int) for id. It has nothing to do with a "not included" key in the url.

{
data: {
"type": "articles",
"id": 1,
"attributes": {
"title": "updated title"
}
}
}

The request is invalid because of the wrong type (int) for "id". It MUST be string (conforming to json api), and jsonapi-resources correctly refuses to process this request, but with this misleading error message.

Suggestion for this Message: "id field is invalid or does not match the id given in the URL."

@lgebhardt
Copy link
Member

Good catch. That error message is a remnant of an early draft of JSON API when a replace operation could target multiple resources. I think it would be most accurate to declare that the resource object does not match the request URL.

Looking at the code in parse_single_replace_operation it could also use some cleanup to reflect the more restrictive nature of the final spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants