The script will be called from a URL like example.com/photo.php?id=123 or example.com/photos/123 depending on if the have the pretty URLs featured enabled.
If photo #123 does not exist, a request to example.com/photos/123 should throw a 404 error. But, what about example.com/photo.php?id=123?
That depends, I suppose.
If photo.php?id=123 is a page showing the photo with an id of 123, then yes, it should throw a 404. 404 means that a resource was not find when it was expected to be found - this is semantically correct.
However, on the odd chance that your semantic intent for photo.php?id=123 was for it to be a page searching for a photo with the id of 123, then it's perfectly correct to return 200 with a message saying that no results were returned.
Ultimately, it doesn't make a huge amount of difference. I'm not very well acquainted with how HTTP response codes affect the way search engines index your page, but I suspect that 404's will not get indexed in the same way. You probably don't want the page being indexed if there's nothing to display.
TL;DR I would throw 404.
Yes, you should throw a 404 if it has never existed:
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
But if it has existed before, you should respond a 410:
The requested resource is no longer available at the server and no forwarding address is know
Hi,
I think you should throw the 404. This you can easily make using a .htaccess file,
Hope that helps,
The relevant RFC is 2616, specifically the sections on status codes, requests, and URIs. Specifically, the query string is considered part of the URI, so a 404 is the proper response since it means:
The server has not found anything matching the Request-URI.
If you can know that a photo has been permanently deleted, you may return 410.
I would not return 200 and say "no results found."