HTTP responses as a service(mock.isssues.com)
mock.isssues.com
HTTP responses as a service
http://mock.isssues.com
16 comments
I have a confession to make. I just spent three minutes trying to work out why http://mock.isssues.com/400 was returning bad request behind ApiAxle...
I'm been using http://httpbin.org/ for this.
Yep. Also:
http://www.mocky.io/, http://ivanzuzak.info/urlecho/, and in some cases: http://hang.nodester.com/
http://www.mocky.io/, http://ivanzuzak.info/urlecho/, and in some cases: http://hang.nodester.com/
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.
No 451 response?
https://tools.ietf.org/html/draft-tbray-http-legally-restric...
https://tools.ietf.org/html/draft-tbray-http-legally-restric...
Yup, sent the author a note on that.
The last time I used something like this it was http://httpstat.us/
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.
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.
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?
What's the good parts of WebDAV and how do they help me make decent RESTful APIs?
RFC4918 is where lots of the status codes people often throw into "REST" APIs came from...
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.
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.
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.
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)
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.
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.
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!
IIRC it also supports simulated response delays. You'll never know the difference!
You should almost always, for almost every test suite, do this with a mocking library.
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.
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.
Are you the creator? FYI, http://mock.isssues.com/timeout gives me an application error instead of returning successfully after 30s.
Result of
Result of
curl -i http://mock.isssues.com/timeout
Must have been fun to implement 418 =)
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.
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.
Nice!
For completeness' sake, also 3xx redirects could be implemented, redirecting to http://mock.isssues.com/200 for example.
For completeness' sake, also 3xx redirects could be implemented, redirecting to http://mock.isssues.com/200 for example.
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.
[deleted]
What happens when you request a non-existent URL at that site?
$ curl -i http://mock.isssues.com/888
HTTP/1.1 404 Not Found
Content-Type: text/html;charset=utf-8
Date: Sun, 21 Jul 2013 22:29:14 GMT
Status: 404 Not Found
X-Frame-Options: sameorigin
X-Xss-Protection: 1; mode=block
Content-Length: 9
Connection: keep-alive
$ curl -i http://mock.isssues.com/fake/url
curl: (6) Could not resolve host: mohttp; nodename nor servname provided, or not known
How do you know that you've implemented 402 correctly?
anmo does all that, and more: https://github.com/sthulbourn/anmo
What about the redirect responses in the 3xx series?