-
Notifications
You must be signed in to change notification settings - Fork 15.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
relatively useless since its so non-informative, let me know if anyone has an objection to this, i think its best to define these for your API
- Loading branch information
Showing
2 changed files
with
0 additions
and
75 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
2bba69f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although there are obviously alternatives, this was actually quite a handy thing to have, specifically in our usage for probing in load balancers. Our HAProxy instances do an httpchk (a probe) using OPTIONS on /, which returned a 200 response (as we've generally always got at least a GET for / set up, that's pretty safe). This was a very simple and unobtrusive way to do probing without having to bake in a specific route for that in to multiple apps. It now returns a 404, which the load balancer considers to be down. I spent a while scratching my head earlier working out what had changed! :)
I'm not saying that it should go back in, just that it did have some uses! What do you think?
2bba69f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah for this we have a
GET /health
end-point2bba69f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I've just written a GET /probe end-point (I assume you mean that you've written a /health end-point - if there's actually one built in which i've missed ignore the following) - maybe it would be a nice feature to have a response baked in to express which was a standard probe-able end-point - /health or something perhaps. Although it's not much code, I've now got a duplicate route across 8 apps and counting :)
2bba69f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nahh IMO it's simple so why not leave it out? don't gain much by adding that sort of thing in, other than having people skip over it and implement their own anyway haha
2bba69f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2bba69f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To close that loop, there's now connect-probe middleware for this. It's in npm, if anyone ever finds this and wants to know! (The middleware way will handle OPTIONS, GET, etc. without writing multiple routes, and has a customisable path, as well as returning uptime if desired). Trivial, but handy.