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

API: Asset by tag endpoint returns 404 instead of 200 #6633

Closed
2 tasks
FlipABit opened this issue Jan 24, 2019 · 1 comment
Closed
2 tasks

API: Asset by tag endpoint returns 404 instead of 200 #6633

FlipABit opened this issue Jan 24, 2019 · 1 comment
Labels
api ✋ bug Confirmed bug
Milestone

Comments

@FlipABit
Copy link

Expected Behavior (or desired behavior if a feature request)

Calling the API URI: /api/v1/hardware/bytag/<asset tag> on an asset tag that does not exist should return an HTTP 200 status code.


Actual Behavior

Calling the API URI: /api/v1/hardware/bytag/<asset tag> on an asset tag that does not exist returns an HTTP 404 status code, with a proper JSON response body.

This is inconsistent with the documentations philosophy: For example, if you made a valid HTTP request to retrieve an asset that doesn't exist, we'll return a 200 OK

Sample Request:

curl -X GET \
  http://<HOST>/api/v1/hardware/bytag/187578 \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer <redacted>' \
  -H 'Content-Type: application/json' \

Response:

< HTTP/1.1 404 Not Found
< Date: Thu, 24 Jan 2019 18:37:07 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Vary: Authorization
< Cache-Control: no-cache, private
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< X-XSS-Protection: 1;mode=block
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: snipeit_session=<redacted>; expires=Sat, 02-Feb-2019 02:37:07 GMT; Max-Age=720000; path=/; httponly
< Content-Length: 62
< Content-Type: application/json
<
* Connection #0 to host 127.0.0.1 left intact

{"status":"error","messages":"Asset not found","payload":null}

Please confirm you have done the following before posting your bug report:


Provide answers to these questions:

  • Is this a fresh install or an upgrade?
    Fresh install (docker image)

  • Version of Snipe-IT you're running
    v4.6.7 - build 3944 (master)

  • Version of PHP you're running

Whichever version is in the latest docker tag.

  • Version of MySQL/MariaDB you're running

MySQL 5.6

  • What OS and web server you're running Snipe-IT on

Ubuntu

  • What method you used to install Snipe-IT (install.sh, manual installation, docker, etc)

Docker

  • What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error

Using the REST API against /api/v1/hardware/bytag/<asset tag>

Please do not post an issue without answering the related questions above. If you have opened a different issue and already answered these questions, answer them again, once for every ticket. It will be next to impossible for us to help you.

https://snipe-it.readme.io/docs/getting-help

@FlipABit FlipABit changed the title API; Asset by tag endpoint returns 404 API: Asset by tag endpoint returns 404 Jan 24, 2019
@snipe snipe added ✋ bug Confirmed bug api labels Jan 24, 2019
@snipe snipe changed the title API: Asset by tag endpoint returns 404 API: Asset by tag endpoint returns 404 instead of 200 Jan 31, 2019
@snipe snipe added this to the v5.0 milestone Feb 5, 2019
@snipe snipe closed this as completed in 971fcf5 Feb 5, 2019
@JonathonReinhart
Copy link
Contributor

I find this behavior to be really confusing. (Returning a 200 when an asset is not found.)

If the asset is found, I get this JSON:

{'asset_tag': '001',
 'assigned_to': {'employee_number': None,
                 'first_name': 'Jonathon',
                 'id': 1,
...
}

but if it is not found, I get this:

{'messages': 'Asset not found', 'payload': None, 'status': 'error'}

So what is the intended way to check for an "asset not found"? To check the status key? That doesn't quite conflict with the status_label key on the valid asset data, but you can see this is kind of ambiguous.

Returning a 404 seems like the expected result. Of course, this leads to ambiguity between an improper request URL, and a properly-formatted request not finding an asset.

This StackOverflow answer makes a reasonable suggestion:

404 for not-found resource; 400 for not-found URL.

But I feel like this might break too many existing consumers...

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

No branches or pull requests

3 participants