It could help to link to some explanation/section in the RFC from the front page error code. Apart from that, this is very nice and potentially useful, thank you very much.
Oh my goodness, I've been looking for this (mocky) for weeks! Thank you. There really isn't much by way of this particular service, and I found it immensely valuable when I used it last.
Last year I was the maintainer for jQuery-Mockjax (https://github.com/appendto/jquery-mockjax) which essentially mocks jQuery's ajax calls. Makes it really easy to test these kinds of conditions on the client without needing to set up a server.
IIRC it also supports simulated response delays. You'll never know the difference!
this looks like a useful service... with one caveat in the form of a rant:
I wish people would stop trying to make response codes into more than they are. Rest does not entail webdav, and without webdav there are not enough semantics to try to do the kinds of things people typically try to make response codes do.
If you are implementing webdav, call it that and stick to the spec, don't just hack a middle ground and pretend you are designing the API properly.
Sadly the http codes were never designed for API calls in the first place, but are the recommended, and accepted way of expressing errors in APIs. The choice is to use woefully vague codes, or move out into other standards such as Webdav. Or of course custom codes.
I've found that many APIs sloppily use parts of webdav and create a fairly ugly hybrid approach.
I think the HTTP codes should be used simply to reflect the transport (in this case HTTP) and any application level stuff should be returned in a systematic way inside the response body. Which means any API call to a valid resource that the user has access to should return a 200.
Then clients can safely assume that if they get a 4xx or 5xx something is breaking, and if it's a 200 then look at the body and deal with the actual response.
Obviously you can add a more detailed payload in the response body for precision, HTTP status codes are the error class (similar to SQL error code classes, or even the error codes themselves for such things as the class 23 codes)
Could you elaborate? My limited experience with WebDAV is what Subversion uses it for, and I've always had the impression that the PROPFIND-type of verbs could just as well be expressed as GET operations on a "property" resource type. I've dismissed WebDAV as "not getting the point" since, but your comment gives me the feeling that that might've been too quick a conclusion.
What's the good parts of WebDAV and how do they help me make decent RESTful APIs?
I'm not a big fan of this practice b/c I've found that as APIs evolve the status codes end up having application specific meaning rather than standard, protocol specific meaning.
Bottom line, I think that unless your API very closely resembles the kind of thing WebDav is designed to do, it's better to just do a simple REST version with core HTTP status codes and handle any standardized response semantics inside the response body.
I'd rather mock stuff like this with a mocking library that doesn't involve making requests to remote servers. The interwebs are (relatively) slow and I want my tests to run fast.
Sometimes you just want to do a quick test and not deal with the complexity of a proper mocking library. But I agree this is not something you'd probably want to bake into a continuous integration build.
30 comments
[ 3.0 ms ] story [ 79.9 ms ] threadIt could help to link to some explanation/section in the RFC from the front page error code. Apart from that, this is very nice and potentially useful, thank you very much.
http://www.mocky.io/, http://ivanzuzak.info/urlecho/, and in some cases: http://hang.nodester.com/
https://tools.ietf.org/html/draft-tbray-http-legally-restric...
Result of
here: http://pastebin.com/nM1VTYwgDid your webserver timeout on your CGI? :)
For completeness' sake, also 3xx redirects could be implemented, redirecting to http://mock.isssues.com/200 for example.
IIRC it also supports simulated response delays. You'll never know the difference!
That being said, I can think of some cases where this service would be really useful, such as one of tests on live systems for example.
I wish people would stop trying to make response codes into more than they are. Rest does not entail webdav, and without webdav there are not enough semantics to try to do the kinds of things people typically try to make response codes do.
If you are implementing webdav, call it that and stick to the spec, don't just hack a middle ground and pretend you are designing the API properly.
I think the HTTP codes should be used simply to reflect the transport (in this case HTTP) and any application level stuff should be returned in a systematic way inside the response body. Which means any API call to a valid resource that the user has access to should return a 200.
Then clients can safely assume that if they get a 4xx or 5xx something is breaking, and if it's a 200 then look at the body and deal with the actual response.
What's the good parts of WebDAV and how do they help me make decent RESTful APIs?
http://datatracker.ietf.org/doc/rfc4918/?include_text=1
I'm not a big fan of this practice b/c I've found that as APIs evolve the status codes end up having application specific meaning rather than standard, protocol specific meaning.
Bottom line, I think that unless your API very closely resembles the kind of thing WebDav is designed to do, it's better to just do a simple REST version with core HTTP status codes and handle any standardized response semantics inside the response body.