4 ms·
> Pushover's API has a message size limitation of 1,024 characters. If the message parameter is larger than that, I could reject the request because it's not co
by Jean-Papoulos 3y ago
> Pushover's API has a message size limitation of 1,024 characters. If the message parameter is larger than that, I could reject the request because it's not correct, but then the user's message is lost and they may not have any error handling. In this case, I truncate the message to 1,024 characters and process it anyway
This guy should not be designing APIs.
- cuu508 3y agoHow would you design it? Accept messages of any length, reject messages over maximum length?
- xctr94 3y agoHTTP 413 Payload Too Large is the appropriate response, not silently truncating content because you wanted to be ‘optimistic’ in your replies to clients.
- madsbuch 3y ago> Pushover's API might be unusual in that it is used by a wide range of devices (embedded IoT things ... If you did that, and no error handling was implemented in the IoT device, it would merely result in a non-event that no one knows about. In this specific instance, the author is doing the right thing. The developer will see truncated messages running through. In the end it is a question on desired semantics. The semantics of the operation in question is obviously to truncate and process rather than fail.
- flir 3y agoPostel's Law? (I actually agree with you, I think it's a bad rule of thumb. I prefer Fail Fast (and loudly)).
- JimDabell 3y agoPostel’s Law is bad and has been the cause of countless bugs, including many security vulnerabilities. Some discussion here: https://news.ycombinator.com/item?id=9824638 https://news.ycombinator.com/item?id=9824638
- kiitos 3y agoThe message in question is being delivered to an end-user device, and is not expected to serve any purpose other than being displayed on a screen. In this context, it seems totally reasonable to truncate overly-long messages.
- lijok 3y agoCertain types of messages have legal and regulatory requirements about their contents. Assuming no such messages traverse your API and truncating them silently is a recipe for disaster.
- deleted 3y ago[deleted]
- kiitos 3y agoYes, that's true. What makes you think that the API described in this post would be subject to those kinds of legal and/or regulatory requirements? Could it be the case that the author knows prima facie that no such requirements exist for their service?
- lijok 3y agoThe API described is not subject to those kind of legal/regulatory requirements. The users of the API may be.
- kiitos 3y agoUsers don't dictate terms, though. How my API works is up to me. If I target use cases that prefer truncation of messages to errors, then surely it's acceptable for me to build it that way, right? I'm not saying it's a good idea in general. I'm saying it can be acceptable in the appropriate context.
- _xnmw 3y agoGiven what Pushover does, I would say it is reasonable. It is a text notification service, not a bank instructions processor. "I'm not receiving any notifications" is likely to be a much more common customer complaint than "my message got truncated". Given that many of the users would not be coding the API integration themselves but using a tool like Zapier, it is reasonable to expect that they don't do text processing on the client side, and it would be the server's responsibility to deal with overflow text.
- JimDabell 3y agoSilently doing the wrong thing / silently discarding user data is bad engineering because it hides an error condition. You want failures like this to be loud not silent, especially if they are infrequent. If a client desires this behaviour, then add a `truncate=true` flag that has to be explicitly passed.
- madsbuch 3y agoWhat would you do in the case, where a developer never anticipates that a message goes above the limit, and hence does not catch and process that category of errors. Later the software is being repurposed, and some low amount, eg. 1%, goes about. But this error is silent.
- fardo 3y agoIf possible, redesigns preceded by targeted warning emails sent to business customers based on message length stats, with a timetable for when the fix will rollout. If that data doesn’t exist, public announcement that the API is breaking long messages without the new parameter. If the API can’t be broken, version the API and break it in the new one and for new customers. In all cases, disclosure in the documentation - If you know there’s a limit and you still exceed it, at that point, as the kids say, FAFO.
- midasz 3y agoIn semver, that's a major version upgrade since it changes the API without being backwards compatible. API consumers have responsibilities too.