Who the fuck puts a size limit on the api endpoint parameter values anyway?

Well, if you would have a database field with a max length of x, you wouldn't want any data on there with a length larger than x, right?

Or am I not understanding correctly?

@linuxxx

Typically an API would be written to insulate/obscure backend data from direct access. The problem that the OP sees is probably the result of development that occurred when some browsers or even programming languages couldn't handle URLs over a certain length, so in a misguided attempt to be uniform or secure, the developer just reduced the entire system to accommodate the least capable client.

Or the dev is just an asshole.

@linuxxx makes sense ... But

Kinda hard to store a 150+ sized token needed right ... And I expected some kind of error response ... But nope

I do. Why?

@netikras are you a @linuxxx clone?

@karma no, I'm not. Do I strike like one?

And why on Earth would I allow you to post a 150GB long text string to updateEmail() endpoint? This data must be buffered and stored on the server somewhere before it can be processed. And processing it prolly involves multiple copying and reading tasks. Do I look like someone who has machinery capable to store petabytes of data [150GB long emails; multiple users posting data] in RAM? That's right, I don't.

That's why I limit your input. Not to just keep up with database restrictions [personally I think limiting api param lengths to match db column restrictions is a bad idea security-wise], like @linuxxx said, but to also avoid [accidental or not] ddos attacks.

A service interface should strictly define all restrictions applied to all params and all returns. Be it a webservice, event-service, local-service or whatever.

I totally understand that an API should have size limitation it's even a security advice that you prevent allowing bigger request size more than needed

Prevent overflows?