HTTP responses as a service

http://mock.isssues.com

by hondo522 • 13 years ago

53 29 13 years ago

mock.isssues.com

claudius• 13 years ago

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.

stevekemp• 13 years ago

The last time I used something like this it was http://httpstat.us/

patjoh• 13 years ago

I'm been using http://httpbin.org/ for this.

izuzak• 13 years ago

Yep. Also:

http://www.mocky.io/, http://ivanzuzak.info/urlecho/, and in some cases: http://hang.nodester.com/

diminoten• 13 years ago

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.

guan• 13 years ago

What happens when you request a non-existent URL at that site?

samuelh2• 13 years ago

$ 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

samuelh2• 13 years ago

$ curl -i http://mock.isssues.com/fake/url curl: (6) Could not resolve host: mohttp; nodename nor servname provided, or not known

nwh• 13 years ago

No 451 response?

https://tools.ietf.org/html/draft-tbray-http-legally-restric...

cbsmith• 13 years ago

Yup, sent the author a note on that.

munimkazia• 13 years ago

What about the redirect responses in the 3xx series?

adsche2• 13 years ago

Are you the creator? FYI, http://mock.isssues.com/timeout gives me an application error instead of returning successfully after 30s.

Result of

    curl -i http://mock.isssues.com/timeout

here: http://pastebin.com/nM1VTYwg

adsche2• 13 years ago

OK works now (with a 28s delay apparently). Can't delete parent.

Did your webserver timeout on your CGI? :)

hondo522• 13 years ago

Heroku was killing the request at 30 seconds, so it worked locally, but failed after deploy.

dlitz• 13 years ago

How do you know that you've implemented 402 correctly?

philjackson• 13 years ago

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...

ville• 13 years ago

Nice!

For completeness' sake, also 3xx redirects could be implemented, redirecting to http://mock.isssues.com/200 for example.

yesimahuman• 13 years ago

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!

spellboots• 13 years ago

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.

grandalf3• 13 years ago

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.

emperorcezar• 13 years ago

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.

grandalf3• 13 years ago

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.

masklinn• 13 years ago

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)

skrebbel• 13 years ago

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?

grandalf3• 13 years ago

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.

jwcrux• 13 years ago

Request: http://mock.isssues.com/{RESPONSE}/{MESSAGE}

AndrewVos• 13 years ago

anmo does all that, and more: https://github.com/sthulbourn/anmo

waxjar• 13 years ago

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.

ams6110• 13 years ago

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.

HTTP responses as a service

Related Stories