The power of types for errors
(This is a cross-post from SoundCloud’s developer blog) At KotlinConf’19 I talked about the power of types. In essence, I discussed limiting the number of primitives we use in our code in favor of using custom types instead. In this way, we as developers will not only reduce the possibility of bugs by using the compiler, but we will also achieve more readable and self-documented types. Today I ran
Designing Errors with Kotlin
The business logic of an application is a description of the schemes by which the application interacts with the user. When a user subscribes, or fills out an order form, or simply logs in, all these actions are processed “under the hood” of the application in a specific order. What data do you need to request? Does the entered data match the specified format? What happens after the user clicks th
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
