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"…}
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.
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?".
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.
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
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.
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.
+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".
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.
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.
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"…}