That's right, eight planets.

• Mercury at /bodies/199
• Venus at /bodies/299
• Earth at /bodies/399
• Mars at /bodies/499
• Jupiter at /bodies/599
• Saturn at /bodies/699
• Uranus at /bodies/799
• Neptune at /bodies/899

Mangled meaning characters are transposed all over the place. It's probably a threading issue. Or maybe bytes are getting dropped somehow? A band-aid would be fetching the data once again if parsing failed, since it doesn't seem to happen often.

The schema for QuantitativeValue has fields for minValue and maxValue. Since the telnet responses sometimes contain an error estimate, like +-0.01, we can calculate this min and max as well. Currently, these error estimations are totally ignored.

Note that some measurements have decimal-place-dependent error measurements, like 1.123+-4, which really means 1.123+-0.004.

HORIZONS has a help menu that shows a bunch of bodies and their IDs, it would be helpful to grab this and display it for an index page or something.

Pluto's response is kinda different from the 8 major planets. It will need some specific parsing rules.

The duration parsing rule defines the seconds and milliseconds portion as

(seconds <"."> milliseconds <"s">)

Most duration values are given as something like 2.123 for two seconds and one-hundred and twenty-three milliseconds. However, this also means that a value like 2.4 would be parsed into two seconds and four milliseconds, not two seconds and four-hundred milliseconds as is intended.

Lots of the dates and times are actually in Barycentric Dynamical Time, not UTC. It's close, but there are slight differences. Research the differences more, and see if it would be worth it to write a Joda time or Java 8 time Chronology class for TDB.

For example, accessing /bodies/199/geophysical-data/escape-velocity would return a simple object like this:

{"unit-code":"M62","value":4.435}

An example of ephemeris data is in the Mars ephemeredes results file.

I would expect the data to be found at /body/{id}/ephemeredes or something similar.

This is what I've decided are the "default" settings:

• Vectors output (enter "v")
• Earth center (hit enter without typing anything)
• "eclip" reference plane
• current system time for start date (hit enter without typing anything)
• now + 14 days ending TDB (hit enter without typing anything)
• Sixty-minute output interval (hit enter without typing anything)
• Accept default output (hit enter without typing anything)

HTTP responses from the API return cache-control and last-modified headers based on the revision dates provided in the Telnet responses. Example:

For an ephemeris request submitted without options, caching must be disabled, or restricted to whatever amount of time the request is still valid. I think the system starts its two-week window at the beginning of the current UTC day, so the response could at least be cached until the end of the day.

Specify start time, end time, and step size, in ISO 8601 format.

Step size cannot be smaller than a minute, and times can't have seconds.

You can enter a partial name and search for bodies, it would be nice to expose that functionality.

I'd love to use plain old maps to represent times, but that's its own can of worms. For now, all timestamp, duration, etc. objects should be the appropriate types from joda time.

Some rules just ignore a stated order-of-magnitude token, so values are usually between one and ten, with an implied order of magnitude. The order of magnitudes for certain fields are different between planets, as well.

This will require the rules to not hide the magnitudes they are parsing, and then have a transformation rule on those fields to convert them to a BigDecimal or something else that can hold one of those big numbers.

Make sure that numbers are put into the correct order-of-magnitude.

The telnet client provides the feature of accessing a planet by IAU name, for example Mars instead of 499. Create a /bodies/search endpoint to pass in a search query. Example:

/bodies/search?q=mars

I am not sure if the telnet application is case-sensitive. I need to do more research on the app's searching functionality.

Units are ignored, at present. Most fields state them, either in the label or after the value, but they are ignored.

Make sure that units get exposed, and end up in the same object with the value, as per the QuantitativeValue schema.

If you connect to HORIZONS, and view the major bodies database with MB, you are given a list of all major bodies the system has information on. I want to make all of these available, at their given IDs.