r-spacex / spacex-api Goto Github PK
View Code? Open in Web Editor NEW:rocket: Open Source REST API for SpaceX launch, rocket, core, capsule, starlink, launchpad, and landing pad data.
License: Apache License 2.0
:rocket: Open Source REST API for SpaceX launch, rocket, core, capsule, starlink, launchpad, and landing pad data.
License: Apache License 2.0
I am not familiar with ruby, but I am guessing that the hash merge of three dictionaries creates one large dictionary. I think you really want an array of the three objects. something like
[$falcon9, $falcon_heavy, $dragon]
but again... not super familiar with ruby
Eg. for tomorrow's launch, does it mean that it doesn't explode while trying to take off, or does it mean that it fails to make it into heliocentric orbit?
Create a Github wiki for API documentation to keep the readme short and concise
The API should return a Content-Type: application/json
header.
Also, a Last-Modified:
header would be nice to allow the creation of a local cache.
I am having a problem with the API. I haven't reached the request level. Although I see "API rate limit reached" message. Waited a night, I still have the same problem.
Sorry if you already debated this before, I was thinking what to expect about the 3 cores of Falcon Heavy.
For launches
now we should get something like:
{
"core_serial": "???",
"rocket": {
"rocket_id": "falcon_heavy",
"rocket_name": "Falcon Heavy",
"rocket_type": "FH1"
},
"land_success": null,
"landing_type": "ASDS",
"landing_vehicle": "OCISLY",
"reused": true,
"reuse": {
"core": false,
"side_core1": true,
"side_core2": true,
"fairings": false,
"capsule": true
}
}
There is a multiple core reuse
but not multiple core_serial
and landing data.
Following the reuse
naming and keeping backward compatibility one could simply add:
{
"core_serial": "B10xx",
+ "side_core1_serial": "B10yy",
+ "side_core2_serial": "B10zz",
"rocket": {
"rocket_id": "falcon_heavy",
"rocket_name": "Falcon Heavy",
"rocket_type": "FH1"
}
}
The same for landing data:
{
"land_success": null,
"landing_type": "ASDS",
"landing_vehicle": "OCISLY",
"land_side_core1_success": null,
"landing_side_core1_type": "RTLS",
"landing_side_core1_vehicle": "LZ-1",
"land_side_core2_success": null,
"landing_side_code2_type": "RTLS",
"landing_side_code2_vehicle": "LZ-2"
}
But feel bloated.
{
"core_serial": [ "B10xx", "B10yy", "B10zz" ],
"land_success": [ null, null, null ],
"landing_type": [ "ASDS", "RTLS", "RTLS" ],
"landing_vehicle": [ "OCISLY", "LZ-1", "LZ-2" ]
}
Feel strange and can break things.
For multiple payloads
there is an array, so something similar for the first stage could be possible adding a rocket.cores
array:
{
"rocket": {
"rocket_id": "falcon_heavy",
"rocket_name": "Falcon Heavy",
"rocket_type": "FH1",
"cores": [
{
"core_serial": "B10xx",
"land_success": null,
"landing_type": "ASDS",
"landing_vehicle": "JRTI"
},
{
"core_serial": "B10yy",
"land_success": null,
"landing_type": "RTLS",
"landing_vehicle": "LZ-1"
},
{
"core_serial": "B10zz",
"land_success": null,
"landing_type": "RTLS",
"landing_vehicle": "LZ-2"
}
]
}
}
If there is no core_serial
, land_success
, landing_type
and landing_vehicle
(which for multiple core seems incorrect anyway) I should find them in rocket.cores
.
This question will arise again for BFR
and ITS
launches, where the latter is a second stage (not a payload) with his own serial
, reuse
, land_success
, landing_type
, landing_vehicle
(and maybe landing_planet
and his own payloads
array).
Looking at vehicles
endpoint and structure,
{
"id": "falcon_heavy",
"name": "Falcon Heavy",
"type": "rocket",
"stages": 2,
"boosters": 2,
"first_stage": {
"reusable": "true",
"engines": 27,
"cores": 3
},
"second_stage": {
"engines": 1,
"payloads": {
"option_1": "dragon",
"option_2": "composite fairing"
}
}
}
a launches
schema supporting more configurations could be:
Falcon Heavy
{
"rocket": {
"rocket_id": "falcon_heavy",
"rocket_name": "Falcon Heavy",
"first_stage": {
"cores": [
{
"core_serial": "B10xx",
"reuse": false,
"land_success": null,
"landing_type": "ASDS",
"landing_vehicle": "JRTI"
},
{
"core_serial": "B10yy",
"reuse": true,
"land_success": null,
"landing_type": "RTLS",
"landing_vehicle": "LZ-1"
},
{
"core_serial": "B10zz",
"reuse": true,
"land_success": null,
"landing_type": "RTLS",
"landing_vehicle": "LZ-2"
}
]
},
"second_stage": {
"payloads": [
{
"cap_serial": "zzzzz",
"payload_type": "Dragon 1.2",
"reuse": true,
"land_success": null,
"orbit": "TLI"
}
]
}
}
}
BFR + ITS
{
"rocket": {
"rocket_id": "bigfalconrocket",
"rocket_name": "Big Falcon Rocket",
"rocket_type": "BFR",
"first_stage": {
"cores": [
{
"core_serial": "xxxxx",
"reuse": true,
"land_success": null,
"landing_type": "RTLS",
"landing_vehicle": "LZ-1"
}
]
},
"second_stage": {
"second_stage_id": "its",
"second_stage_type": "ITS",
"second_stage_serial": "yyyyy",
"reuse": true,
"land_success": null,
"landing_type": "ASDS",
"landing_vehicle": "OCISLY",
"payloads": [
{
"payload_type": "Satellite",
"orbit": "LEO"
}
]
}
}
}
Should be
core_serial: "1035.2"
landing_type: "RTLS"
reused: true
...
Scheduled for 2017-12-08T13:20:00-04:00
.
How do you deal with standard time? Right now EST = UTC-5
Sorry for all the issues being reported. This one's two parts
When fetching cap or core info for a single part (example: https://api.spacexdata.com/v1/parts/cores/B1036) it shouldn't return an array, just a single object
Also, the wiki entry for cap endpoints is incorrect. It lists the url as
https://api.spacexdata.com/v1/parts/caps/C106/
when it should be
https://api.spacexdata.com/v1/parts/caps/C106
as the first url produces an error
example url https://api.spacexdata.com/v1/launches/upcoming
FormoSat-5
launch_date_utc: 2017-08-24T18:50:00
X-37B OTV-5
launch_date_utc: 2017-08-28T00:00:00Z
As you can see, sometimes they specify a time zone, sometimes not...
instead of /parts/cap=C106 you should use /parts/caps/C106 which follows a more common rest structure. This is pretty common syntax when fetching details on a particular rest object. The same things goes for cores
:)
Current example: https://api.spacexdata.com/v1/launches/upcoming?start=2017-10-30&final=2017-11-06
Output:
{
"error": "No Matches Found"
}{
"error": "No Matches Found"
}[]
{
flight_number: 45,
launch_year: '2017',
launch_date_utc: '2017-08-14T16:31:00Z',
launch_date_local: '2017-08-14T12:31:00-04:00',
rocket: 'Falcon 9',
rocket_type: 'FT',
core_serial: 'B1039',
cap_serial: 'C113',
launch_site: {
site_id: 'ksc_lc_39a',
site_name: 'KSC LC 39A'
},
payloads: [
[Object]
],
launch_success: null,
reused: null,
land_success: null,
landing_type: null,
landing_vehicle: 'LZ-1',
links: {
mission_patch: null,
reddit_campaign: 'https://www.reddit.com/r/spacex/comments/6mrga2/crs12_launch_campaign_thread/',
reddit_launch: null,
reddit_recovery: null,
reddit_media: null,
presskit: null,
article_link: null,
video_link: null
},
details: null
}
I am getting lots of errors in my code
When I do JSON.parse(data)
on the response I get from the server I get the output as above. Notice how in data.payloads[0]
there is just [Object]
. But data.lauch_site
is fine.
After some research, I think this could be because the JSON is 'double encoded', although I'm not sure if that is something that is the responsibility of the server or the client.
Or I have got completely the wrong end of the stick!
Edit: This is the code I use to parse the JSON data, note that it isn't throwing an error, only later when I try to access data within data.payloads[0]
res.setEncoding('utf8');
let rawData = '';
res.on('data', (chunk) => { rawData += chunk; });
res.on('end', () => {
try {
const parsedData = JSON.parse(rawData);
console.log(rawData);
console.log(parsedData);
// some code to pick the relevant company data from the user request (request.body.result.parameters.CompanyParams)
callback(app, parsedData)
} catch (e) {
console.error(e.message);
}
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:
{
"id": "dragon1",
"caps": ["Dragon 1.0", "Dragon 1.1", ...],
"cores": ["B0004", "B0005", ...],
...
}
I'd appreciate the effort!
GET https://api.spacexdata.com/v1/launches/latest
returns a JSON response which points to a static Flight Club simulation result in the telemetry
attribute. The id
in the Flight Club query string is the id of a specific simulation - so this will never update itself.
Rather than have the returned URL in the form
https://www.flightclub.io/results/?id=5f90f4b8-3e5f-41ef-aa1a-4551254b2589&code=OTV5
a better format is to remove the id
attribute so you're left with
https://www.flightclub.io/results/?code=OTV5
What Flight Club does behind the scenes is find the id
of the most recent, most accurate and up-to-date mission simulation. Often, this estimate is made after the mission when there is a webcast to use as a reference point - so these estimates are always much more accurate than a specific guess and can only get more accurate over time, without the need for you to change anything.
If you're curious what the actual simulation id
is in this scenario, you can find it by querying
https://www.flightclub.io:8443/FlightClub/api/v1/missions/?code=OTV5
and looking for the livelaunch
attribute.
Add a version number to endpoints to allow for better version stability as the endpoints continue to solidify over time, instead of adding breaking changes continuously.
On https://github.com/r-spacex/SpaceX-API/wiki/Upcoming-Launches the word combination is misspelled.
All upcoming launches can be filtered though any **conbination** of the following querystrings
I looked to see if there was a way to edit the wiki to fix it, but it doesn't appear it's publically editable.
Comparing /vehicles to /launchpads, the error messages for invalid id's are not consistent, complicating error handling.
GET https://api.spacexdata.com/v1/vehicles/bad
{ "error": "No Endpoint Found" }
Status code is 404: Not Found
GET https://api.spacexdata.com/v1/launchpads/bad
{ "error": "No Matches Found" }
Status code is 200: OK
Both would return the 'No Matches Found' message. I have no opinion on status code, though the most REST-ful would be 404's in both cases.
Where'd you get 07-04 from?
rocket
key for Falcon 1 and rocket_name
for Falcon 9: it should be the same key.payload_type
is Satelite
, it should be Dragon 1.1
.Satellite
is mispelled as Satelite
.For CRS flights, we lack:
Now that capsule reuse is a thing and fairing reuse is not far, we should get a better definition of "reused".
My idea would be to have a section like this, depending of the vehicule type:
reuse: {
booster: true,
sidebooster1: false,
sidebooster2: true,
fairings: true,
capsule: false,
}
But I'm not sure if it would the best way to do it.
disclaimer: might be the same for capsules
example
https://api.spacexdata.com/v2/launches/latest
The core serial is listed as B1032.2 but if you then hit https://api.spacexdata.com/v2/parts/cores/B1032.2
It's incorrect. The serial is actually B1032
If it makes sense to suffix the serial with a .X for number of flights, that could be a separate field.
Is there a reason for this change? It makes some sense, but there is no no "friendly" name provided for each launch site in the launches endpoint
The first Orbcomm mission has a payload name of "Orbcomm-OG2 x 6", while the second one has a name of "Orbcomm OG2 M2". Either the second one should be changed to "x 11" or the first one should be changed to "M1".
The example snippets of the Wiki section still outdated. Even though it says v2 already but the code snippet still displaying the outdated "rocket" object.
Zuma currently has a payload mass of 0
, which naturally isn't correct. I think setting it to null
makes the most sense, as a value is not known.
https://api.spacexdata.com/launches
The time_local
does not specify the time zone.
Also, there will be (rare) cases where time_utc
and time_local
occur on different days, it will, therefore, be ambiguous as to which the launch_date
agrees with.
Possible solutions to the latter would be:
In: https://api.spacexdata.com/launchpads
SLC 40 is given as
"id": "ccafs_slc_40",
"full_name": "Cape Canaveral Air Force Station Space Launch Complex 40",
However in https://api.spacexdata.com/launches
"launch_site": "CCAFS LC-40"
The different naming structure makes comparisons and between the different API topics difficult. For example, if one wanted to get information about the launch site Amos-6 flew from CCAFS LC-40
then the user's code must translate it to ccafs_slc_40
and also
"launch_site": "KSC LC39A"
notice the different use of -
First of nice work with the API. Haven't worked too much with Ruby, so not sure if I'd be much help on the tech side (more a .NET dev), though considering making a Windows app (desktop, mobile, xbox).
Little tweaks that would be useful or things I noticed:
Like I said above, I'm more a .NET dev, but if you want to bounce any ideas or problems of me let me know. My day job is working with MVC WebAPI. Nice work :)
shouldn't customers be an array of strings? instead of listing them as customer_1, customer_2?
the way it is right now makes it tough to parse because there could be an unknown number of customers. I think it should be something like...
customers: ["NASA", "TSA", "USAF"]
Please feel free to post any suggestions, corrections, or additions I should make to the data. I'll try my best to keep it as current as possible ๐
Thanks!
After getting some funny javascript behaviour in my server logic I found the issue.
So apparently we got the wrong end of the stick with the ISO datetimes.
For example, Intelsat 35e reads
"launch_date_utc": "2017-07-05T23:35:00Z",
"launch_date_local": "2017-07-05T23:35:00-04:00",
But should read
"launch_date_utc": "2017-07-05T23:35:00Z",
"launch_date_local": "2017-07-05T19:35:00-04:00",
So the correct format for a local time is
local_year
-local_month
-local_day
Tlocal_hour
:local_minutes
:local_seconds
+/-timezone_correction
and not UTCDateTime+/-timezone_correction
If you query by core or capsule, currently any further launch query parameters are ignored, e.g. year, start, final, site.
I'd expect something like https://api.spacexdata.com/v1/launches/caps/C106?year=2017 to only return the launch from 2017.
The Falcon 9 vehicle has 10 engines. 9 Merlin, 1 Merlin Vac.
https://api.spacexdata.com/vehicles/falcon9
This is really neat stuff, I'm gonna take a closer look.
Hi Jake,
I've noticed a couple of changes in the returndata of the api endpoints:
Hi! Awesome work. I would love to fix this except my familiarity with where the hell this would be located in a web app like this is...low.
The data when I hit /launches
for launch 38 shows an invalid landing ship - "OSCILY" instead of "OCISLY". Caught this when using this API to build out a sample iOS app. Gotta love strict typing.
If someone can point me to where this can be adjusted I'd be happy to open a PR - if it's just something which needs to be updated at the DB level though, it's wherever the landing_vehicle
JSON parameter is generated.
The Core for SpaceX CRS-12 is listed as C113 but I believe that should be the cap_serial
For each launch site object, in addition to having an id and a name, it would be great to have a "long name".
ksc_lc_39a
:
ccafs_slc_40
:
vafb_slc_4e
:
I'm not sure how do you input new data, but it looks like some of mongo documents have very different properties within same collection. It is important to know what to expect in the results form the api user perspective.
I started a branch to add more assertions for results https://github.com/Srokap/SpaceX-API/tree/more_assertions and noticed that ie. dragon capsule and falcon rockets data differs wildly. The launches data has single launch with missing UTC timestamp.
So main question is about approach to take to make api useful for it's users that need to make assumptions about what to expect in results. We could track it in tests, or we could validate data when being put into db. In this use case, making extensive input tools might be not worth the effort, so we might run travis on master on schedule instead (don't remember if Travis allows to run tests on demand).
Did a change happen recently that disabled CORS? I was planning to use this data in a demo at a conference this week. The conference is unrelated to SpaceX, NASA or space in general... just a tech conference and thought it was a cool dataset.
But suddenly seeing errors related to CORS. The response headers look very different too... looking back through the commits I don't see anything that says CORS was disabled.
here: https://api.spacexdata.com/v1/launches/upcoming
flight numbers are strings
whereas here: https://api.spacexdata.com/v1/launches
flight numbers are numbers
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.