Roy T. Fielding wrote and described REST in his dissertation in the 2000's. He basically told about the an architectural pattern and mapped it to most common protocol: HTTP

Since these days the IT community began to realize and to understand more and more what it means to deal with resources, what power and strength HTTP provides. But what's so special about it? And why does everybody talk about it but the least understood it? Why is today everything called REST, but in fact it's not REST? Let's dig into it.

In many software systems and use cases there are exceptions. Exceptions, that are triggered by conditions that do not allow the expected sequence (ideally). These exceptions and dealing with those are hiding behind the lapidary used "exception handling". A fast-created try-catch is often not the solution. And in those cases in which exceptions are forwarded to the client, there are some pitfalls.

Exceptions, yes, what are exceptions? Exceptions are situations, where the planned flow cannot be completed anymore. So they are exactly the same as dealing with business logic. Exceptions are only a more elegant mechanism. They allows us to provide in an emergency case (unexpected parameters, errors in file access) an adequate response.

In vielen Software-Systemen und Use Cases gibt es Ausnahmen. Ausnahmen, die durch Zustände ausgelöst werden, die nicht den erwarteten Ablauf (Idealfall) ermöglichen. Diese Ausnahmen und der Umgang verbirgt sich hinter dem lapidar benutzten "Exception Handling". Dabei ist ein schnell erstellter try-catch oftmals nicht die Lösung. Und in den Fällen, in denen Exceptions an den Client weitergeleitet werden, gibt es einige Fallstricke.