Add System ID to /characters/{character_id}/contracts/

[alexbaileyuk]

Feature Request

When looking at contracts via the ESI, it would be useful to have the system ID included in the response similar to 'start_location_id' and 'end_location_id'. You could use 'start_system_id' or 'end_system_id'.

Using the above existing fields is cubersome and usually you're not bothered if a contract is in a specific structure. Furthermore, there is seemingly no way to translate a location ID to a system ID. For example, location ID 1031461794475. It appears to not be accepted by any of the look up endpoints.

Instead, we have to use a reference to look up the type of location it is and then go to look up the location (reference)

A different solution could be to add the location type to the location so for example 'start_location_id': 123456 becomes 'start_location': {'id': 123456, 'type': station}. Possible types could be citadel, station etc.

Use case

Anyone dealing with contracts who wants to aggregate details by system ID. For example, alliances checking that dotrines are stocked or contract seeders checking their own stock levels.

Authentication

Both solutions above use the existing contract endpoint which already has auth required.

Example return

[
  {
    "start_system_id": 12345,
    "end_system_id": 1235543,
    ...rest of contract details
  }
]

Alternatively:

[
  {
    "start_system": {
      "id": 123,
      "type": "station"
    },
    "end_system": {
      "id": 45432,
      "type": "citadel"
    },
    ...rest of contract details
  }
]

Checklist

Check all boxes that apply to this issue:

• Feature request description is provided
• Use case exists
• Feature requires a new route
• Feature adds data to existing route
• Feature requires new auth scope
• Feature can reuse existing scope
• Feature does not require auth
• Meta feature, applies to all routes

[Blacksmoke16]

Given ESI's past nature of reducing redundant data, I'm not so sure this will be approved.

Instead, we have to use a reference to look up the type of location it is and then go to look up the location (reference)

Is this really a problem? AFAIK there can only be two "types" of origin, a structure or a station, which you can easily deduce based on the size of the ID. I.e. something like:

path = location_id > 1_000_000_000_000 ? 
  "/universe/structures/#{location_id}/") : 
  "/universe/stations/#{location_id}/")

...

I would think it's easy enough to get this data thru the {start,end}_location_id.

[alexbaileyuk]

@Blacksmoke16 get what you're saying in which case how about a better way to lookup a location? Right now there is no way to translate a location ID through the ESI. It requires knowledge that cannot be found in the ESI API Spec or the docs at present which doesn't feel right.

[alexbaileyuk]

Also, when you have found what you want in the ESI, you can't just do:

path = location_id > 1_000_000_000_000 ? 
  "/universe/structures/#{location_id}/") : 
  "/universe/stations/#{location_id}/")

Because one endpoint returns system_id and one returns solar_system_id :/

[Blacksmoke16]

Right now there is no way to translate a location ID through the ESI. It requires knowledge that cannot be found in the ESI API Spec or the docs at present which doesn't feel right.

It is documented, https://docs.esi.evetech.net/docs/id_ranges.html. You also have to take the context of the endpoint you're using into consideration. In this case contracts can only ever originate from a structure or a station, so doing a simple check on the size of the location_id is easy enough.

I would also suggest/assume you're keeping a database of previously resolved locations; this would make what you want easier as you only have to resolve locations you haven't seen before.

Because one endpoint returns system_id and one returns solar_system_id :/

That is an issue on its own, see #1029. But I'm not sure I see how that fits into this discussion.

Either way, I'll leave this open for some other @esi/ecm to give their thoughts. Then we can go from there.

[lukasni]

I think this is a valid request, not because of the extra requests required, but because the character may not have access to the start/end location if they are structures. Thanks to the structure deliveries system, those contracts may still be of interest, and having a way of resolving the system id in those cases would be good.

[ddouglas]

This could be abused. If somebody gives an app access to contracts but not to structures, exposing the solar_system_id in the contract exposes where the solar system that structure exists (obviously). Using this, somebody could easily build a list of solar system <=> structures. Even if they can't resolve the structure id to figure out which type of structure it is.

[lukasni]

Hm, that's a fair point. On the other hand, /markets/{region_id}/orders/ already has a similar leak for ranged orders, and that's on a public route. Hard to balance it I suppose, comes back to the more general issues with working with structures from ESI.

[ddouglas]

Good Point, wasn't aware of that. Just wanted to point it out. Not saying this wouldn't be valuable, that is just the first thing that came to mind.

[alexbaileyuk]

@Blacksmoke16 you're right I did not see that documented. Well spotted.

@ddouglas this is character contracts though. The player can see in game the system that the structure is located by opening the contract details so I fail to see a security hole here.

@lukasni I agree that being able to identify that a contract is in a structure the user has no access to is also a valid use case here. This would likely be useful to JF pilots etc.

[CarbonAlabel]

Closely related to #1017.

As I commented in that issue, adding system IDs to the endpoints would be a reasonable solution, which has previously been used for the market endpoints (#450).

[Blacksmoke16]

After thinking on this more, I agree it's a good idea.

EDIT: This would actually be super helpful for a project I'm currently working on.