This webpage does some funky history writing on firefox and chrome on scroll, so just scrolling through the page you get dozens of fragments in your visit history. You need to click back a dozen times before you get out of the page depending on how far you scroll!
Nah, it's just that scrolling updates the URL the same way the sidebar links do, so it gets added to your browser history. Seems like an honest mistake.
I'm the author of the tool used to generate the doc.
And yes this is just my mistake (I don't use back button so much during testing so never noticed this). Will fix it asap.
My guess is that this was built for practice. That said, some of the data is coming back bad. The 'url' property contains an address that is missing the 'u' and 'a'. https://ghibliapi.herokpp.com
+1, although it can be challenging - Ghibli covers are extremely popular in Japan, they are now classics and even Ghibli themselves pushed different albums at different times. It's a bit like trying to get the original for "The Girl from Ipanema".
"There was this one time I trolled HN into upvoting my web API for some shitty japanese anime or something. So yeah, I guess I'm famous in tech circles."
It's not the first time I see this claim in a REST API. What is it supposed to mean? Does it hint at some form of automatic (machine-driven) discovery, or is it just a pompous way to say they expose capabilities via a REST API?
a principal of REST which is often ignored or improperly implemented is hypermedia-driven discovery. You should be able to discover the entire api via a top-level entry point which will return a bunch of links.
The more I look at this the more it feels like an unofficial random project endpoint relying on trademark infringement to look important and get extra publicity than a case of "who the hell at Ghibli thought this was needed and decided to build this?".
Now it can be loaded into Pandas for analysis. Even if I was building an app I'd want to own the data 1) so my users aren't being logged by the API service 2) control over the uptime 3) lower latency 4) flexibility of serving the data, such as generating static pages.
It's like the extremely popular Pokeapi (https://pokeapi.co) or SWAPI (https://swapi.co): a service providing data over a REST interface. In other words, an API.
It's honestly the first time I see anyone claiming "an API is not an API unless it changes something".
API stands for "Application Programming Interface". A website that serves up data is not an API. The best way to explain the difference is that you can write an API on a piece of paper and it is still an API (i.e., you don't have to implement it). It documents how different parts of an application interface with each other. Normally it consists of things like the definitions of functions that you can call to achieve various results.
An API is specifically not a service. You can have many services that all use the same API. REST itself is an API. You can build another API on top of REST. So if someone says they have a REST API for querying movie information, that's sensible. If you have a service that serves up movie information, that's not an API. That's a service. It uses an API.
It might seem pedantic, but I have talked with otherwise talented programmers who didn't actually know what an API was. They mentioned using "the API" in their front end code and when I asked the only reasonable question, "Which API?" they didn't know how to respond. They've got about a billion libraries in their front end code (like everyone else ;-) ) and each one of them has an API -- otherwise they couldn't use it. However "API" only meant talking to the server to them.
I realise common usage is trumping the original definition of the term, but I think that's to the detriment of everyone involved.
Object {id: "2baf70d1-42bb-4437-b551-e5fed5a87abe", title: "Castle in the Sky", description: "The orphan Sheeta inherited a mysterious crystal t…uta's science to make himself ruler of the world.", director: "Hayao Miyazaki", producer: "Isao Takahata"…}
I struggle to understand the general negativity of this thread. Like zillions of other projects seen on HN, this is just someone playing around and offering a service others may or may not find interesting.
Sure, the dataset is currently small, but it can easily get bigger if anyone starts doing things like marking appearance times, quotes with translations, pictures and so on.
Sure, it might not be an official Ghibli project, in the same way IMDB or ComicDB did not start as official projects.
I personally find it fun and will look into building something with it, just for kicks. One obvious application would be a GMap mashup with locations, at least for the realistic films. Another would be a Youtube mashup with clips for each element.
Sometimes the internet seems too cynical even for a sad old fart like me.
If you ever find yourself assigning a unique URL to a thing which has a name and a type, and assigning a unique URL to the type which has a name and a supertype, consider dusting off rdf:type and rdf:subClassOf and maybe JSON-LD rather than reinventing something very similar.
56 comments
[ 3.1 ms ] story [ 125 ms ] thread2) It's a bunch of text data; as the link posted in another comment shows, it's less than 50kB uncompressed.
[0] https://github.com/Rebilly/ReDoc
That's a fantastic hiring signal, unlike being a jerk on the internet.
Pick one.
We detached this flagged subthread from https://news.ycombinator.com/item?id=13997270.
It's not the first time I see this claim in a REST API. What is it supposed to mean? Does it hint at some form of automatic (machine-driven) discovery, or is it just a pompous way to say they expose capabilities via a REST API?
https://en.wikipedia.org/wiki/HATEOAS
- SOAP had discovery
- XML based REST APIs had discovery (via HATEOAS)
- JSON based REST APIs inevitably never have discovery (looks like there's no standard JSON version of the 'link rel' from HATEOAS)
- GraphQL has discovery
More usefully, this isn't an API, it's a data source for in-universe facts! It has an API (but is not one).
Mods? "Studio Ghibli dataset" or something?
It's honestly the first time I see anyone claiming "an API is not an API unless it changes something".
An API is specifically not a service. You can have many services that all use the same API. REST itself is an API. You can build another API on top of REST. So if someone says they have a REST API for querying movie information, that's sensible. If you have a service that serves up movie information, that's not an API. That's a service. It uses an API.
It might seem pedantic, but I have talked with otherwise talented programmers who didn't actually know what an API was. They mentioned using "the API" in their front end code and when I asked the only reasonable question, "Which API?" they didn't know how to respond. They've got about a billion libraries in their front end code (like everyone else ;-) ) and each one of them has an API -- otherwise they couldn't use it. However "API" only meant talking to the server to them.
I realise common usage is trumping the original definition of the term, but I think that's to the detriment of everyone involved.
To save anybody from copy-and-pasting it, here's ten seconds of playing around:
> ghibli
Object {films: Array(20), people: Array(16), locations: Array(25), species: Array(5), vehicles: Array(3)}
> ghibli.films[0]
Object {id: "2baf70d1-42bb-4437-b551-e5fed5a87abe", title: "Castle in the Sky", description: "The orphan Sheeta inherited a mysterious crystal t…uta's science to make himself ruler of the world.", director: "Hayao Miyazaki", producer: "Isao Takahata"…}
> ghibli.locations[0]
Object {id: "11014596-71b0-4b3e-b8c0-1c4b15f28b9a", name: "Irontown", climate: "Continental", terrain: "Mountain", surface_water: "40"…}
> ghibli.people[0]
Object {id: "ba924631-068e-4436-b6de-f3283fa848f0", name: "Ashitaka", gender: "male", age: "late teens", eye_color: "brown"…}
Besides, being an API it can be extended with things like quotes, exact appearance times etc etc.
It's not an official Studio Ghibli API. But it's exactly what you'd build if you were learning to build APIs.
* http://i.imgur.com/gySIZ.png
* http://farm2.static.flickr.com/1258/1355972123_12a28bd3b6.jp...
Seeing that the peehole is forward would make it male no? This little toy also seems male:
* https://img0.etsystatic.com/110/0/11763563/il_570xN.88580129...
I'll be sure to ask the opinion of my friends next time I play with their cats! Btw I am not trying to argue. I'm just curious.
Sure, the dataset is currently small, but it can easily get bigger if anyone starts doing things like marking appearance times, quotes with translations, pictures and so on.
Sure, it might not be an official Ghibli project, in the same way IMDB or ComicDB did not start as official projects.
I personally find it fun and will look into building something with it, just for kicks. One obvious application would be a GMap mashup with locations, at least for the realistic films. Another would be a Youtube mashup with clips for each element.
Sometimes the internet seems too cynical even for a sad old fart like me.