Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
linuxxx15570811dWell, 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?
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.
netikras566411dI do. Why?
netikras566411d@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.
Ma30h613711dI 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
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job