ebowman / api-first-hand

API-First bootstrapping tool for building RESTful web services from a Swagger/OpenAPI spec
MIT License
142 stars 22 forks source link

fix parser inlude types #61

Closed gipeshka closed 7 years ago

gipeshka commented 7 years ago

Reasoning:

When parser creates the model it creates invalid references e.g.:

Field("definitions" / "User" / "counts", Opt(TypeDef("paths" / "/users/{user-id}" / "get" / "responses" / "200" / "data" / "counts", Seq(
    Field("paths" / "/users/{user-id}" / "get" / "responses" / "200" / "data" / "counts" / "media", Opt(BInt)), 
    Field("paths" / "/users/{user-id}" / "get" / "responses" / "200" / "data" / "counts" / "follows", Opt(BInt)), 
    Field("paths" / "/users/{user-id}" / "get" / "responses" / "200" / "data" / "counts" / "follwed_by", Opt(BInt))))))))))))

https://github.com/zalando/api-first-hand/blob/master/swagger-parser/src/test/resources/expected_results/types/instagram.api.yaml.types#L814

As one can see field with reference ⌿definitions⌿User⌿counts refers typedef with reference ⌿paths⌿/users/{user-id}⌿get⌿responses⌿200⌿data⌿counts which is incorrect.

This happens only with objects inside other objects because function fromTypes replaces name for all fields on the first level of an object.

The actual issue is that the next step - flattener might extract type with wrong type reference. This will cause modelConverter to fail while resolving type using not existent reference.

Currently type flattener tests don't fail because during flattening of instagram api example flattener imports right ⌿definitions⌿User mapping after the incorrect one during the same iteration on https://github.com/zalando/api-first-hand/blob/master/api-first-core/src/main/scala/de/zalando/apifirst/TypeFlattener.scala#L127

But it might be a case if typeDefs map will have different ordering.

This pr fixes initial issue in the parser.

slavaschmidt commented 7 years ago

Great, thanks!