These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

RESTful API to access data from the static SQL dump, such as item and station details.

Author
Kouryusei
Keizai Inc
#1 - 2012-03-26 18:43:34 UTC  |  Edited by: Kouryusei
Currently heavily in progress, but have exposed the ability to look up details of an item or station based on typeID or stationID. Further methods will be exposed in the next few days. You can specify whether you want JSON or XML returned.

Item Lookup

URL
http://rest.bitterseatrading.com/static/type/id/(typeid).(json/xml)

Example (Tritanium)
http://rest.bitterseatrading.com/static/type/id/34.json

Station Lookup

URL
http://rest.bitterseatrading.com/static/station/id/(stationid).(json/xml)

Example (Kulelen V - Moon 8 - Zainou Biotech Production)
http://rest.bitterseatrading.com/static/station/id/60001822.json

Notes

The id parameter must be the last parameter referenced in the query string. All other parameter calls should be made prior to it, such as version.
Dern Morrow
Dreddit
Test Alliance Please Ignore
#2 - 2012-03-26 19:04:47 UTC
Hi, this is a great idea. I have some suggestions:

* Allow the user to specify a version. I.e., allow us to say "I want the output from the Crucible 1.1 data dump" or something. I'd rather not have my programs "automatically upgrade" because that may confuse things. (Of course, if someone doesn't specify a version, you should return the latest. This fulfills the needs of both groups of people.)

* Similarly, the output should include a version field. That way when the new version comes out, we won't have to guess at whether or not you've updated your source yet.

* The URL format of "blah/format/json" is kind of weird. I would suggest either "blah.json" (an extension) or just using the HTTP Accept header. (I.e., "Accept: application/json" from the client indicates that they want JSON.) The extension method is slightly easier for people, but the Accept header is technically correct and more RESTful.

* The numbers in the output should be numbers, not quoted strings.

Anyway, this is great. Thank you for doing this.
Kouryusei
Keizai Inc
#3 - 2012-03-26 19:09:25 UTC  |  Edited by: Kouryusei
Dern Morrow wrote:
Hi, this is a great idea. I have some suggestions:

* Allow the user to specify a version. I.e., allow us to say "I want the output from the Crucible 1.1 data dump" or something. I'd rather not have my programs "automatically upgrade" because that may confuse things. (Of course, if someone doesn't specify a version, you should return the latest. This fulfills the needs of both groups of people.)

* Similarly, the output should include a version field. That way when the new version comes out, we won't have to guess at whether or not you've updated your source yet.

* The URL format of "blah/format/json" is kind of weird. I would suggest either "blah.json" (an extension) or just using the HTTP Accept header. (I.e., "Accept: application/json" from the client indicates that they want JSON.) The extension method is slightly easier for people, but the Accept header is technically correct and more RESTful.

* The numbers in the output should be numbers, not quoted strings.

Anyway, this is great. Thank you for doing this.


I'd definitely like to include the version function, you can expect that in the next day or so. Give me time to grab and import the data! You'll be able to specify a version via the /version parameter.

-

Allowing .json and .xml to be specified as the URL extension instead of the method call is on the roadmap and should be in by this time tomorrow. This would change the URL to the following.

rest.bitterseatrading.com/static/type/version/1.1/id/34.json

I will look in to accepting a request header to specify the format as well, this should be fairly easy to implement.

--

In terms of the returned data, I'm working on type conversion at the moment. It's been a PITA!
Desmont McCallock
#4 - 2012-03-26 19:53:31 UTC
I believe that the following url format would be better
'http://rest.bitterseatrading.com/static/cru1.1/type.json?id=34'
''http://rest.bitterseatrading.com/static/cru1.1/station.json?id=60001822'
Kouryusei
Keizai Inc
#5 - 2012-03-26 20:02:31 UTC
Desmont McCallock wrote:
I believe that the following url format would be better
'http://rest.bitterseatrading.com/static/cru1.1/type.json?id=34'
''http://rest.bitterseatrading.com/static/cru1.1/station.json?id=60001822'


Will take this under consideration.
Dern Morrow
Dreddit
Test Alliance Please Ignore
#6 - 2012-03-26 20:40:07 UTC
Desmont McCallock wrote:
I believe that the following url format would be better
'http://rest.bitterseatrading.com/static/cru1.1/type.json?id=34'
''http://rest.bitterseatrading.com/static/cru1.1/station.json?id=60001822'


At the end of the day, all that matters is that people can understand it and it works as advertised... the exact structure of the URL is a flame war that has been going on since REST was even proposed.

In the spirit of REST, though, each URL should identify a "resource". This can be done with query string parameters, but it is most commonly not. I.e., in this case, since we're talking about an object type, the URL would "most properly" be something like "/type/34" and the URL would be the same regardless of the output format.

But we programmers are contentious beasts. Some of us like one thing, some another, and really all that matters is that the API be understandable and supportable... :)
Kouryusei
Keizai Inc
#7 - 2012-03-27 08:56:16 UTC
The URL format has now been changed, please see the first post for details.
Osku Rei
Pixel 6
#8 - 2012-03-28 15:49:32 UTC
Desmont McCallock wrote:
I believe that the following url format would be better
'http://rest.bitterseatrading.com/static/cru1.1/type.json?id=34'
''http://rest.bitterseatrading.com/static/cru1.1/station.json?id=60001822'


No, fail.

Next generation of lottery tracker coming soon! http://evelotterytracker.com/

Please like my post if it has helped you :)