{"id":43,"date":"2015-05-17T14:00:49","date_gmt":"2015-05-17T18:00:49","guid":{"rendered":"http:\/\/george.hotelling.net\/91percent\/?p=43"},"modified":"2015-05-16T23:05:15","modified_gmt":"2015-05-17T03:05:15","slug":"restful-responses-and-angular","status":"publish","type":"post","link":"https:\/\/george.hotelling.net\/91percent\/2015\/05\/17\/restful-responses-and-angular\/","title":{"rendered":"RESTful responses and Angular"},"content":{"rendered":"

Testing for an empty JSON document<\/a><\/p>\n

\n I have a RESTful service that performs a search and returns the results as JSON, and if there\u2019s no results I return an empty document, {}.\n<\/p><\/blockquote>\n

Now I don’t know what the original author’s situation is or how much control they have over the API they’re consuming, but I can definitely project my own experiences on his blog post. At the link above he provides is a good example of the right solution to the wrong problem. It handles the response given, but the response itself is the real problem.<\/p>\n

When you are using a RESTful web service to search and it cannot find anything, you shouldn’t wind up in this situation to start with. The fix isn’t better client code, the fix is a better web service.<\/p>\n

When your service does a search without finding anything, it should return 404 Not Found<\/a>. I’ve had to deal with too many web services that only had 2 response codes: 500 if there was an uncaught exception or 200 OK for everything else. There is a sea of other HTTP response codes<\/a> and limiting yourself to just those two limits the usefulness of your service.<\/p>\n

If Angular gets a 404 response it won’t invoke the .success()<\/code> block, it will go straight to .error()<\/code> handler. (.success()<\/code> and .error()<\/code> have their own issues but that’s another blog post) That would have prevented this situation in the first place. In my project at work we are doing just this: a search that doesn’t find anything returns a 404. When people have looked at our network traffic they have complained to us about these errors, but by sticking to HTTP semantics we’ve avoided this all together.<\/p>\n

“But it shouldn’t return an error code if the service executes without errors!” – The 400 series of status codes is for client<\/strong> errors, requests that can’t be fulfilled. If I request a URL that doesn’t have a file on a static website, I get a 404. Why should it be different if I request an ID that doesn’t exist in your database? Why should a search for something that doesn’t exist and may never have been OK?<\/p>\n

“But I don’t want errors in my code!” – When you add RESTful web services to your architecture, you are making HTTP part of your execution flow. A 404 response is kind of like an exception: you don’t want to hide it from your client any more than you would want to catch all exceptions<\/a>. Let the client decide what to do when nothing is found, don’t try to pretend everything is OK.<\/p>\n

So please, if you’re exposing a web service over HTTP use Status Codes correctly. Or don’t, it gives me something to blog about<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Testing for an empty JSON document I have a RESTful service that performs a search and returns the results as JSON, and if there\u2019s no results I return an empty document, {}. Now I don’t know what the original author’s situation is or how much control they have over the API they’re consuming, but I … Continue reading RESTful responses and Angular<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[6,7],"class_list":["post-43","post","type-post","status-publish","format-standard","hentry","category-programming","tag-angular","tag-rest"],"_links":{"self":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts\/43","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/comments?post=43"}],"version-history":[{"count":10,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts\/43\/revisions"}],"predecessor-version":[{"id":51,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/posts\/43\/revisions\/51"}],"wp:attachment":[{"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/media?parent=43"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/categories?post=43"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/george.hotelling.net\/91percent\/wp-json\/wp\/v2\/tags?post=43"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}