Update proposal based on discussion from forums

Author: Gayathri Sairamkrishnan

Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0011.md

@@ -10,6 +10,11 @@ Improve error handling by adding the ability for mapping application errors to H
 - Issue: [apple/swift-openapi-generator#609](https://github.com/apple/swift-openapi-generator/issues/609)
 - Affected components:
     - runtime
+- Versions:
+    - v1.0 (2024-09-19): Initial version
+    - v1.1(2024-10-07):
+      - Replace the proposed solution to have a single error handling protocol, with the status being required and
+        headers/body being optional.
 
 ### Introduction
 
@@ -18,7 +23,8 @@ introduces a way for users to map errors thrown by their handlers to specific HT
 
 ### Motivation
 
- When implementing a server with Swift OpenAPI Generator, users implement a type that conforms to a generated protocol, providing one method for each API operation defined in the OpenAPI document. At runtime, if this function throws, it's up to the server transport to transform it into an HTTP response status code – for example, some transport use `500 Internal Error`.
+ When implementing a server with Swift OpenAPI Generator, users implement a type that conforms to a generated protocol, 
+ providing one method for each API operation defined in the OpenAPI document. At runtime, if this function throws, it's up to the server transport to transform it into an HTTP response status code – for example, some transport use `500 Internal Error`.
 
 Instead, server developers may want to map errors thrown by the application to a more specific HTTP response. 
 Currently, this can be achieved by checking for each error type in each handler's catch block, converting it to an 
@@ -46,7 +52,7 @@ If a user wishes to map many errors, the error handling block scales linearly an
 
 The proposed solution is twofold.
 
-1. Provide protocol(s) in `OpenAPIRuntime` to allow users to extend their error types with mappings to HTTP responses.
+1. Provide a protocol in `OpenAPIRuntime` to allow users to extend their error types with mappings to HTTP responses.
 
 2. Provide an (opt-in) middleware in OpenAPIRuntime that will call the conversion function on conforming error types when
 constructing the HTTP response.
@@ -62,20 +68,19 @@ The proposal aims to provide a transport agnostic error handling mechanism for O
 
 #### Proposed Error protocols
 
-Users can choose to conform to one of the protocols described below depending on the level of specificity they would 
-like to have in the response. 
+Users can choose to conform to the error handling protocol below and optionally provide the optional fields depending on
+the level of specificity they would like to have in the response. 
 
 ```swift
-public protocol HTTPStatusConvertible {
+public protocol HTTPResponseConvertible {
     var httpStatus: HTTPResponse.Status { get }
-}
-
-public protocol HTTPHeadConvertible: HTTPStatusConvertible {
     var httpHeaderFields: HTTPTypes.HTTPFields { get }
+    var httpBody: OpenAPIRuntime.HTTPBody? { get }
 }
 
-public protocol HTTPResponseConvertible: HTTPHeadConvertible {
-    var httpBody: OpenAPIRuntime.HTTPBody { get }
+extension HTTPResponseConvertible {
+    var httpHeaderFields: HTTPTypes.HTTPFields { [:] }
+    var httpBody: OpenAPIRuntime.HTTPBody? { nil }
 }
 ```
 
@@ -92,10 +97,11 @@ public struct ErrorMiddleware: ServerMiddleware {
         do {
             return try await next(request, body, metadata)
         } catch let error as ServerError {
-            if let appError = error.underlyingError as? HTTPStatusConvertible else {
-                return (HTTPResponse(status: appError.httpStatus), nil)
-            } else if ... {
-              
+            if let appError = error.underlyingError as? HTTPResponseConvertible else {
+                return (HTTPResponse(status: appError.httpStatus, headerFields: appError.httpHeaderFields), 
+                appError.httpBody)
+            } else {
+                throw error
             } 
         }
     }
@@ -107,9 +113,9 @@ There's no mechanism to prevent the users from inadvertently transforming a thro
 
 #### Example usage
 
-1. Create an error type that conforms to one of the error protocol(s)
+1. Create an error type that conforms to the error protocol
 ```swift
-extension MyAppError: HTTPStatusConvertible {
+extension MyAppError: HTTPResponseConvertible {
     var httpStatus: HTTPResponse.Status {
         switch self {
         case .invalidInputFormat: