Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
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?
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.
I do. Why?
@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.
Ma30h58492yI 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