2017年、API界隈で起こる変化について | NTT Communications Developer Portal
マイクロサービス システムをごく小さくまとめ、APIベースで機能を提供するマイクロサービスがより広がっていくと考えられます。多くのモノリシックなシステムにおいて密結合が拡張性やメンテナンス性において負の資産となっています。マイクロサービス化することで結合ポイントを減らし、開発を容易にします。 マイクロサービスは多くがモデルデータのCRUD操作をREST APIにて提供します。HTMLを返すものは多くありません。まさにAPI向けの施策と言えるでしょう。ただし、サービスの分け方をうまくやらないと、ただシステムが細分化されただけで複雑なシステム構成になってしまいます。 最近ではマイクロサービス用のフレームワークも登場し、開発がより簡単になっています。次の段階としてはアーキテクチャであったり、サービスの切り分け方に関するソリューションが共有される年になっていくことでしょう。 Swagger 昨年で
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
