Comments on: REST Web Services, the Book http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/ Thoughts on PHP, eBay, and too many technical topics for my family's liking. Thu, 18 Feb 2010 23:21:22 +0000 http://wordpress.org/?v=2.9 hourly 1 By: Ben Ramsey http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/comment-page-1/#comment-103064 Ben Ramsey Fri, 15 Jun 2007 18:21:44 +0000 http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/#comment-103064 I know I'm very late to this discussion, but I would argue that a 404 error for a zip code that doesn't exist is inappropriate for GET /search?zip=12345 because the resource /search technically exists. However, if you changed it to GET /search/zip/12345, then a 404 error is completely appropriate because the /search/zip/12345 resource does not exist. I do not think the query string is part of the requested resource even though it affects the requested resource. I know I’m very late to this discussion, but I would argue that a 404 error for a zip code that doesn’t exist is inappropriate for GET /search?zip=12345 because the resource /search technically exists. However, if you changed it to GET /search/zip/12345, then a 404 error is completely appropriate because the /search/zip/12345 resource does not exist. I do not think the query string is part of the requested resource even though it affects the requested resource.

]]> By: Jörn Horstmann http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/comment-page-1/#comment-19977 Jörn Horstmann Mon, 06 Nov 2006 21:19:17 +0000 http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/#comment-19977 I think that a wellformed HTTP can also result in a 4xx kind of error, like a request for a non-existent resource which results in a 404. This would seem like a good solution to your example of an invalid zip code. The combination of search parameters results in a url like 'search?zip=12345' and an 404 status would be the expected outcome of manually modifying an url. Of course this would only work if the upstream server reports meaningful error messages or additional fault codes that one can map to client errors. If I could not trace the error back to some faulty parameters the client supplied, I would return a 5xx status code. I think that a wellformed HTTP can also result in a 4xx kind of error, like a request for a non-existent resource which results in a 404. This would seem like a good solution to your example of an invalid zip code. The combination of search parameters results in a url like ’search?zip=12345′ and an 404 status would be the expected outcome of manually modifying an url.

Of course this would only work if the upstream server reports meaningful error messages or additional fault codes that one can map to client errors. If I could not trace the error back to some faulty parameters the client supplied, I would return a 5xx status code.

]]> By: Adam Trachtenberg http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/comment-page-1/#comment-19938 Adam Trachtenberg Mon, 06 Nov 2006 18:19:50 +0000 http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/#comment-19938 Jörn -- Makes sense. Where I run into issues is around the phrase "client seems to have erred." Is this referring to the format of the request or its content? Or both? If I have something that's valid HTTP, but the data that's provided is invalid for the web service, is that 2xx or 4xx? The client generated a valid request structurally, but the user operating the client made the client pass along invalid data. Likewise, what happens when I have stacked clients and servers? My PHP script is both a server (processing AJAX requests from the browser) and a client (sending SOAP requests to eBay). If there's a client error (4xx) between me and eBay should that turn into a server error (5xx) between me and the web browser? Or stay a client error? Should I not expose this nature to the browser? I am thinking not, as why should it matter if the data is being gathered from a web service or a database, but I want to make sure. Jörn –

Makes sense. Where I run into issues is around the phrase “client seems to have erred.” Is this referring to the format of the request or its content? Or both?

If I have something that’s valid HTTP, but the data that’s provided is invalid for the web service, is that 2xx or 4xx? The client generated a valid request structurally, but the user operating the client made the client pass along invalid data.

Likewise, what happens when I have stacked clients and servers? My PHP script is both a server (processing AJAX requests from the browser) and a client (sending SOAP requests to eBay). If there’s a client error (4xx) between me and eBay should that turn into a server error (5xx) between me and the web browser? Or stay a client error?

Should I not expose this nature to the browser? I am thinking not, as why should it matter if the data is being gathered from a web service or a database, but I want to make sure.

]]> By: Leonard Richardson http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/comment-page-1/#comment-19900 Leonard Richardson Mon, 06 Nov 2006 14:48:03 +0000 http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/#comment-19900 If you send me your email I'll send you the current version of the appendix. There's also a list of status codes in "HTTP: The Definitive Guide". I haven't actually gone through that list and normalized it against the appendix. If you send me your email I’ll send you the current version of the appendix. There’s also a list of status codes in “HTTP: The Definitive Guide”. I haven’t actually gone through that list and normalized it against the appendix.

]]> By: Jörn Horstmann http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/comment-page-1/#comment-19862 Jörn Horstmann Mon, 06 Nov 2006 12:18:14 +0000 http://www.trachtenberg.com/blog/2006/11/06/rest-web-services-the-book/#comment-19862 An overview of the status codes can be found in rfc 2616 (http://rfc.net/rfc2616.html#p58). Status codes starting with 4 are used when the error seems to be on the client side, codes starting with 5 should be used for server errors. An overview of the status codes can be found in rfc 2616 (http://rfc.net/rfc2616.html#p58). Status codes starting with 4 are used when the error seems to be on the client side, codes starting with 5 should be used for server errors.

]]>