Verifying HTTP method in handler – a pointless exercise?

Written by
Link to Post

Hi all,

A friendly debate in work (if there is one) spawned the following:

I work for a top 250 website and we have a JS front end which points to Go APIs behind the scenes via HTTP.

We’re obsessed with performance due to our high traffic, so we streamline any code (even if it leads to bad code practice, sigh).

We have an API which handles incoming GET requests – when we enter the handler, should we check the HTTP method?

i.e. if r.Method != http.MethodGet { w.WriteHeader(http.StatusMethodNotAllowed) return }

Argument: Remove • We get rid of an unnecessary check when (we assume) it’s going to error out anyway later on • The front end is never going to call the service with a PUT, POST etc

Argument: Keep • It’s much safer as we don’t have to assume it’s going to error later (and worst of all, assuming it’s a GET could cause a panic later • We can weed out bad calls early on and prevent them unnecessarily going through the logic

What do you guys think?

submitted by /u/stizzo96
[link] [comments]

Article Tags:
· ·
Article Categories:

Leave a Reply