3 ms·
The 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 conte
by kiitos 3y ago
The 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.