Return arrays instead of objects for many GETs #16
Conversation
|
i'm looking at this and not sure why this is being changed. What's wrong with the returned object? More parsing? My main concern is not wanting to keep two different versions of the monorail.yml. One for this and one from the main. The monorail.yml is automatically generated from the RackHD code. Manually editing this will lead to future issues. |
|
If you can get RackHD/on-http#292 merged, I won't hesitate to move this further. But I think that monorail.yml is our "source of truth" |
|
I totally agree about the upstream monrail.yml being our source of truth. I'd like them to be identical soon. I also apologize - I totally missed your PR, RackHD/on-http#175, when I submitted all of mine to RackHD. You had already solved several of the problems I hit. :( |
|
@codenrhoden same here as #17. anything that needs to be updated before merge since it has been included upstream? |
Many of the return schemas here are actually arrays of objects, not just a single object. Makes for more accurate generated code from Swagger.
codenrhoden
force-pushed
the
return_arrays
branch
from
a642bba
to
70ab0d1
Compare
|
@kacole2 this is now good to go as well. Passed the 4 local tests for GET/POST/DELETE/Lookup... I may do one more PR in the the next few days to re-synch the two monorail.yml files for good, but right now things are looking great! Thanks for all your help. |
Matching PR to RachHD is here: RackHD/on-http#292
Many of the GET schemas are wrong, listing the return as a generic object instead of a list of objects. Fix that.
Also, remove all the extra whitespace from
monorail.ymlin a separate commit.Probably want to merge #15 first, and then I can rebase this one on top of it. But it can be reviewed as-is.