HTTP 413 Payload Too Large is the appropriate response, not silently truncating content because you wanted to be ‘optimistic’ in your replies to clients.

> 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.

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.

Certain 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.

Yes, 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?

The API described is not subject to those kind of legal/regulatory requirements. The users of the API may be.

Users 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.

Postel's Law?

(I actually agree with you, I think it's a bad rule of thumb. I prefer Fail Fast (and loudly)).

Postel’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