servant-errors 0.1.2.0 → 0.1.3.0

raw patch · 5 files changed

+30/−14 lines, 5 filesPVP ok

version bump matches the API change (PVP)

API changes (from Hackage documentation)

Files

CHANGELOG.md +9/−0
README.lhs +8/−4
README.md +8/−4
servant-errors.cabal +1/−1
src/Network/Wai/Middleware/Servant/Errors.hs +4/−5

CHANGELOG.md view

@@ -20,3 +20,12 @@ ## 0.1.1.0  * support more GHC versions (8.2 - 8.6)++## 0.1.2.0++* fix reversed object key fields in errors++## 0.1.3.0++* fixes PlainText HasErrorBody instance+* couple of code refactors

README.lhs view

@@ -8,11 +8,15 @@  This package implements a wai-middleware targeting servant-server applications with a goal of make it easier to generate custom server error responses. +### Checkout accompanying blogpost for more details.++* [Unifying Servant server error responses](https://lukwagoallan.com/posts/unifying-servant-server-error-responses)+ ## Motivation -By default, when your servant server application experiences an internal exception during endpoint route resolution, e.g. request body decode errors. The server response is just plain text with a status code in the HTTP headers.+By default, when your servant server application experiences an internal exception during endpoint route resolution, e.g. request body decode errors, the server response is just plain text with a status code in the HTTP headers. -At the same time, if you don't write custom code to customise error responses for errors thrown within servant route handlers the default response is plain text with an HTTP content-type if set within `ServerError`.+At the same time, if you don't write custom code to customise error responses for errors thrown within servant route handlers; the default response is plain text with an HTTP content-type when provided within `ServerError`.  With `servant-errors`  library, you get a single interface to structure and encode your error responses in one place as `JSON` error response or any other preferred form. @@ -22,7 +26,7 @@ main :: IO () main = run 8001 (serve proxyApi handlers) --- | With servant-errors as error processing middleware+-- | With 'errorMw' from servant-errors library as an error processing middleware main :: IO () main = run 8001      $ errorMw @JSON @'["error", "status"]@@ -42,7 +46,7 @@      $ serve proxyApi handlers ``` -This [blog post](https://lukwagoallan.com/posts/unifying-servant-server-error-responses) explains in more details.+  ## Complete Usage Example

README.md view

@@ -8,11 +8,15 @@  This package implements a wai-middleware targeting servant-server applications with a goal of make it easier to generate custom server error responses. +### Checkout accompanying blogpost for more details.++* [Unifying Servant server error responses](https://lukwagoallan.com/posts/unifying-servant-server-error-responses)+ ## Motivation -By default, when your servant server application experiences an internal exception during endpoint route resolution, e.g. request body decode errors. The server response is just plain text with a status code in the HTTP headers.+By default, when your servant server application experiences an internal exception during endpoint route resolution, e.g. request body decode errors, the server response is just plain text with a status code in the HTTP headers. -At the same time, if you don't write custom code to customise error responses for errors thrown within servant route handlers the default response is plain text with an HTTP content-type if set within `ServerError`.+At the same time, if you don't write custom code to customise error responses for errors thrown within servant route handlers; the default response is plain text with an HTTP content-type when provided within `ServerError`.  With `servant-errors`  library, you get a single interface to structure and encode your error responses in one place as `JSON` error response or any other preferred form. @@ -22,7 +26,7 @@ main :: IO () main = run 8001 (serve proxyApi handlers) --- | With servant-errors as error processing middleware+-- | With 'errorMw' from servant-errors library as an error processing middleware main :: IO () main = run 8001      $ errorMw @JSON @'["error", "status"]@@ -42,7 +46,7 @@      $ serve proxyApi handlers ``` -This [blog post](https://lukwagoallan.com/posts/unifying-servant-server-error-responses) explains in more details.+  ## Complete Usage Example

servant-errors.cabal view

@@ -1,6 +1,6 @@ cabal-version:       2.2 name:                servant-errors-version:             0.1.2.0+version:             0.1.3.0 synopsis:            Servant Errors wai-middlware description:         A Wai middleware that uniformly structures errors with in a servant application. The library assumes all HTTP responses with status code greater than 200 and without an HTTP content type are error responses. This assumption is derived from servant server error handling implementation.

src/Network/Wai/Middleware/Servant/Errors.hs view

@@ -70,7 +70,7 @@ import GHC.TypeLits (KnownSymbol, Symbol, symbolVal) import qualified Network.HTTP.Media as M import Network.HTTP.Types (Header, Status (..), hContentType)-import Network.Wai (Response, Middleware, responseHeaders, responseLBS, responseStatus,+import Network.Wai (Middleware, Response, responseHeaders, responseLBS, responseStatus,                     responseToStream) import Servant.API.ContentTypes (Accept (..), JSON, PlainText) @@ -118,7 +118,7 @@     encodeError = encodeAsPlainText (getErrorLabels @errLabel @statusLabel)  instance HasErrorBody PlainText '[] where-  encodeError = encodeError @JSON @["error", "status"]+  encodeError = encodeError @PlainText @["error", "status"]  -- | 'errorMwDefJson' is a convenience pre-configured function for middleware -- that encodes error responses as @JSON@ objects using @error@ and @status@@@ -141,10 +141,9 @@   baseApp req $ \ response -> do      let status      = responseStatus response          mcontentType = getContentTypeHeader response-         processResponse = newResponse @ctyp @opts status response >>= respond      case (status, mcontentType) of-       (Status 200 _, _)                     -> respond response-       (Status code _, Nothing) | code > 200 -> processResponse+       (Status code _, Nothing) | code > 200 ->+         newResponse @ctyp @opts status response >>= respond        _                                     -> respond response   where     getContentTypeHeader :: Response -> Maybe Header