redcrewos / api-sdk-creator-js Goto Github PK

Feature Summary

Add an implementation of HttpClient that uses the fetch API

Feature Rationale

For browser applications, a third party client library like axios won't be required.

Feature Summary

Add an implementation of HttpClient that uses in build node http and https modules.

Feature Rationale

This allows server side code (eg: lambdas) to make outbound HTTP requests without needing to install a client library like request or axios

The current POC of the generator combines validation with transformation which isn't the best idea.

Validation should be broken into a separate phase and not only checks that the input is valid against the various JSON schemas that define the Open API spec, but also that semantics of the spec makes sense, for example, do $refs resolve correctly.

In order to perform schema validation correctly, there needs to be a list of the various schemas used and how they're comprised as schemas extend/consume other schemas.

The first version of the validator should target Open API versions 3.0.x and 3.1.x while being extendable to add Swagger 2 support

Currently the generator uses a set of transformation functions to transform the API spec into an AST for code generation eg: inlining references.

Using Optics (lenses) is a better way of achieving the same outcome but in a simpler, more composable fashion.

See more

• https://itnext.io/a-beginners-guide-to-ramda-part-2-lenses-62bdd3993598
• https://www.youtube.com/watch?v=tvHghZBMVJU
• https://github.com/calmm-js/partial.lenses

Describe the bug
When receiving a response with no body (eg: an HTTP 204), the JSON unmarshalling fails with an error

UnhandledPromiseRejectionWarning: Error: Unexpected end of JSON input

To Reproduce

1. Setup an HTTP server to return a success response with no body eg:

res.statusCode = 200;
res.end();

2. Setup a client pipe that uses the @api-sdk-creator/axios-http-client HttpClient that uses the jsonUnmarshaller

(async function run() {
 const client = pipeK(
   createAxiosHttpClient(),
   jsonUnmarshaller()
 );

 await client({
   url: "http://localhost:3000"
 }).toPromise()
}());

Expected behaviour

HTTP call should execute successfully with no body in the HTTP response.

Versions:

• Node version: v12.21.0
• @api-sdk-creator/http-api-client version: 0.0.1
• @api-sdk-creator/axios-http-client version: 0.1.1

Additional context
Add any other context about the problem here.

Currently the error reporting for the generator is not helpful in identifying which location/path of the spec is invalid.

Validation of the spec should probably be a separate phase so that transformation functions can operate on the spec without having to worry about invalid data.

Describe the bug
When receiving a HTTP 204 response with no body but a JSON content type, the JSON unmarshalling fails with an error

UnhandledPromiseRejectionWarning: Error: Unexpected end of JSON input

To Reproduce

1. Setup an HTTP server to return a 204 response with a JSON content type but no body eg:

res.writeHead(204, {
    "content-type": "application/json; charset=UTF-8"
});

res.end();

2. Setup a client pipe that uses the @api-sdk-creator/axios-http-client HttpClient that uses the jsonUnmarshaller

(async function run() {
 const client = pipeK(
   createAxiosHttpClient(),
   jsonUnmarshaller()
 );

 await client({
   url: "http://localhost:3000"
 }).toPromise()
}());

Expected behaviour

API call should execute successfully.

Versions:

• Node version: v12.21.0
• @api-sdk-creator/http-api-client version: 0.0.2
• @api-sdk-creator/axios-http-client version: 0.1.3

Additional context

This is extension of the issue from #1. The fix that was made for that issue checked the Content-Length response header to see if content is meant to present in the response and fix the Axios HTTP response to have an undefined body. However according to the HTTP spec a HTTP 204 response is not allowed to have a Content-Length header, therefore the solution is incomplete. When compensating for Axios, the status code needs to be considered too.

This is currently a very ambiguous issue. However the goal is to know that the generator can process any OAS 3 or 3.1 spec. To do that, a set of abstractions around the AST the generator uses internally will need to be produced, along with tests to ensure that an API spec can be parsed (with all different variations the spec allows) into an AST that can then be used to generate code.