Enable the generated server-side code to validate the content-type.

[takeshi-1000]

Motivation

I am interested this tool and have selected something that I can work on.
Resolve #16

Modifications

To validate content-type header string in server program, I modify traslateServerDesirializer method .

Result

For example you will define below opeapi yaml

  /greet:
    post:
      operationId: postGreeting
      requestBody:
        required: true
        content:
          text/plain:
            schema:
              type: string

when you try the request, runtime error happen.

$ curl localhost:8080/api/greet -X POST \             
> -H "Content-Type: application/json" \
> -d '{ "name": "foo" }'

{"error":true,"reason":"Server error - operationID: postGreeting, request: path: \/api\/greet, query: <nil>, method: HTTPMethod(value: OpenAPIRuntime.HTTPMethod.(unknown context at $106e9fd78).OpenAPIHTTPMethod.POST), header fields: [Host: localhost:8080, User-Agent: curl\/7.88.1, Accept: *\/*, Content-Type: application\/json, Content-Length: 64], body (prefix): { \"name\": \"foo\"}, metadata: path parameters: [:], query parameters: [], operationInput: <nil>, operationOutput: <nil>, underlying error: Unexpected Content-Type header: application\/json"}

Test Plan

I have made the necessary changes to adapt to the newly generated code on the reference server side and have confirmed that it passes the tests locally.

[czechboy0]

Hi @takeshi-1000, thanks for taking this up!

Overall, your change looks good, can you just add a unit test? For example, you could create a variant of the test for createPet (here) that purposefully passes the incorrect content type and verifies that an error was thrown with XCTAssertThrowsError (but no need to test the contents of the error, as it's an internal type).

[takeshi-1000]

@czechboy0
Thank you for reviewing .
I tried to add, but XCTAssertThrowsError seems not to supported async method.
https://developer.apple.com/documentation/xctest/1500795-xctassertthrowserror

I am considering the following code, but is there any better alternative?

 client = .init(
            createPetBlock: { input in
                return .created(
                    .init(
                        headers: .init(
                            X_Extra_Arguments: .init(code: 1)
                        ),
                        body: .json(
                            .init(id: 1, name: "Fluffz")
                        )
                    )
                )
            }
        )
        
        do {
            _ = try await server.createPet(
                .init(
                    path: "/api/pets",
                    method: .post,
                    headerFields: [
                        .init(name: "x-extra-arguments", value: #"{"code":1}"#),
                        .init(name: "content-type", value: "text/plain; charset=utf-8"),
                    ],
                    encodedBody: #"""
                        {
                          "name" : "Fluffz"
                        }
                        """#
                ),
                .init()
            )
            XCTFail("The method should have thrown an error.")
        } catch {
            XCTAssertNotNil(error)
        }

[czechboy0]

Ah you're right. Yeah, a manual do/catch block, where you XCTFail at the end of the do block, and do nothing in the catch block is how I've worked around this limitation.

[czechboy0]

Two more suggestions, just to simplify the tests a bit more, otherwise looks good. 👍

[takeshi-1000]

Thank you for checking ! I applied your suggestion .

[czechboy0]

Looks great, thank you!

[czechboy0]

@swift-server-bot add to allowlist

[czechboy0]

Actually, the change looks good, just added a suggestion on how to fix the red CI.

[takeshi-1000]

I missed https://github.com/apple/swift-openapi-generator/blob/main/CONTRIBUTING.md#run-scriptssoundnesssh, and am confirming .

[simonjbeaumont]

Thanks @takeshi-1000 for getting involved!