New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for object relation #69
Comments
First option should be no problem, Don't really know how to aggregate the data to form the second example. I'll look into it further. Only issue I see is a conflict between different params on the same endpoint, for example:
|
Perhaps a search param, like the following could to the trick: I've checked the database and I think it can be done by adding |
I think I understand now, makes sense to add it to caps. What about cores though? |
Whoops, I wasn't aware about the cores entity and what it meant in the context of the rocket. I know now that it's all about the 1st stage? Since these aren't necessarily linked to a specific type of rocket but more to a build, the cores endpoint I specified above can be ignored. Sorry ;-) |
Changes are live, I'll update the wiki shortly |
Thanks Jake! |
Hi @jakewmeyer, was just wondering, would it be possible to query capsule parts and core parts via capsule id as well? That'd be very useful for connecting all together!
So instead of querying the api with this:
https://api.spacexdata.com/v2/parts/caps?type=Dragon 1.1
We could query like this, returning an array of caps or cores for this main type:
https://api.spacexdata.com/v2/parts/caps/dragon1
https://api.spacexdata.com/v2/parts/cores/dragon1
Or, instead of the above, send a small array of subtypes in the response object:
https://api.spacexdata.com/v2/capsules/dragon1
returns:I'd appreciate the effort!
The text was updated successfully, but these errors were encountered: