4 ms·
As well as ID, we'll do some fuzzy matching on the URLs as well, so GET /api/vehicle/t-65-x-wing and GET /api/planets/mustafar will also work
by paulhallett 12y ago
As well as ID, we'll do some fuzzy matching on the URLs as well, so
GET /api/vehicle/t-65-x-wing
and
GET /api/planets/mustafar
will also work
- lttlrck 12y agoThis doesn't work on pokeapi.co
- paulhallett 12y agoPokeAPI is getting an update - http://phalt.co/if-you-have-data-they-will-consume-it/ http://phalt.co/if-you-have-data-they-will-consume-it/ and it will have better fuzzy matching.
- anonfunction 12y agoI think it would be nice to also provide an endpoint that lists all the resources as an array of objects where the key is the id and the value is the name. Maybe something like this: GET /resources/ships [ { 1 : "Tantive IV" }, ]
- paulhallett 12y agoSo RESTfully, I think this is normal. You should be able to call a resource and then be fed back all of those resources (usually paginated to say, 20 per request). It will have this style of lookup.
- svsaraf 12y agoDo you mind discussing how you did the fuzzy matching? My initial guess would've been dynamic programming (levenstein distance), but if this is API-wide, did you make a suffix tree?