Quesa
Burning Napalm
Northern Coalition.
82
   |
Posted - 2015.09.11 19:23:04 -
[3] - Quote
I just notice that if I attempt to query a CorporationSheet with a bad ID, I get back an HTTP Status Code 500, which is supposed to denote an internal server error.
However, there is a response sent back for:
https://api.eveonline.com/corp/CorporationSheet.xml.aspx?corporationID=0
which is:
http://i.imgur.com/SYsWXhq.png
My understanding of this HTTP Status Code 500 means that there was an actual server software or hardware malfunction. W3.org definition of 500: "The server encountered an unexpected condition which prevented it from fulfilling the request."
If the resource isn't found then wouldn't it be more appropriate to return a 404? |
Quesa
Burning Napalm
Northern Coalition.
83
|
Posted - 2015.10.10 10:15:50 -
[4] - Quote
On the topic of cacheing the paged, static data responses, I'm not sure why you cannot cache each type and then combine multiple cached items into one response. For instance, tables like solar systems, regions, and types are static for each db version which only changes during patches. Why not cache each one of those entries then allow someone to query info for a single or array of IDs:
/solarsystem/?systemID=1234
or
/solarsystem/?systemID=1234,1235,1236.
That way, you're never touching the DB layer. Furthermore, could that system not be used in your cacheing? If someone queries character info for a single character, that data is cached for an hour and returned to anyone else requesting that data whether it be for a single query:
?characterID=1234
or as part of a larger query
?characterID=1234,1234,1235
Quote:Actually this isn't inconsistent at all. Technically if we follow the design pattern /market/10000002/orders/buy/ should return all market buy orders for the region regardless of type. The type parameter is a filter. /market/regionID/orders/buy/orderID is the next step in the URI. /market/regionID/orders/buy/ is also where the post request goes for creating a new buy order. /market/regionID/orders/buy/ is a collection or buy orders, and following RESTful design should, and does just not exposed to third-party devs yet, a way of viewing an individual item from that collection. The parameters should then filter, which is what we have in the above design. The only questionable part of that is the region ID being part of the URI and not a parameter, but that's because of the way our backend works. the market is divided into regions and must be viewed per region, it's not an optional parameter. Again, type should really be optional... that might be the inconsistent part.
I have yet to run across any other REST service that uses that formatting. It's awkward as you're using IDs everywhere else. Is this somehow more efficient on your end? In the example used, not only is regionID a filter but so is buy so what makes the version using a URI as a parameter more RESTful than
/market/{ regionID }/orders/buy/{ typeID }
or
/market/{ regionID }/orders/buy/?typeID={ typeID }, { typeID }
less RESTful compliant than the way it is now? The suggested way, imo, is more readable. |