json-ld (part 3 of 3)

Subject: json-ld (part 3 of 3)

• note: originally emailed 06/24/2014 and sanitized for public consumption
• sidenote: posting here so i can lead people here whenever they ask me about this stuff...
• series: part 1 & part 2

---

Let me first say, I can see why they want all of this stuff:

• xmlns:
• RDF
• JSON-LD
• And finally -- from the only [usable] JSON-LD implementation available so far [that I know of so far]
• a Hydra powered web API via symfony

This is the java nerds sticking their dirty fingers with a kung-fu death grip in the web world trying to make themselves still relevant.

Anyways, here's a HOWTO on getting "a" webby API thingie working with this JSON-LD stuff...


In a nutt shell
First, you need to know that Hydra is installed via "a" PHP package manger called Symfony

• If you are interested in learning about Symfony, here's the brain dead simple howto:
• http://symfony.com/doc/current/quick_tour/the_big_picture.html
• Note: this installs locally and can be safely deleted
• Just note that will require a running DB (e.g. mysql)

Now, install the sample hydra demo (so you have a working version to play with)

• https://github.com/lanthaler/sfHydraDemoApp
• Part 1 [of the demo] should look familiar if you did the crash course above
• When you get to part 3 [of the demo]: pay attention to the last line:
• "Please note that it will return JSON-LD so you might wanna access it using cURL or the Hydra Console"

Then there's "HydraBundle" -- which I'm guessing is a way to shove this Hydra server in your Symfony project.

• https://github.com/lanthaler/HydraBundle

My analysis
Anyways, the Hydra demo implementation has confirmed my suspicion -- the webserver (or whatever RESTy box) needs to handle the URI path (as the parameter to your "handler")

• E.g. http://webserver/account/foo/bar
• In this case, the following does not actually exist on the "web server":
• account/foo/bar
• account/foo
• account
• and yes, the webserver walks those paths first
• to see why, check out http://wiki.nginx.org/Pitfalls
• "Passing Uncontrolled Requests to PHP"
• Nick's mad HACK tip of the day!
• finally, (in this case) a "index" file -- at http://webserver/ would take over
• the demos have this file as "app.php"
• this file takes and read the URI path and processes it by (depending on the php implementation) walk the "path" as the parameters for the request
• so, http://webserver/app.php would process [ account/foo/bar ] and do with it as necessary

Side note: I've never used Symfony in the past -- and after this little exercise, I don't think I'll ever use it in the future...

• Really? [A] java build system that compiles PHP code to include a bunch of other PHP frame work code...
• And the "compiled" PHP code isn't even optimized -- cached, yes, but the number of files "loaded" is still HUGE
• Yes, it's nice that it automates some steps, does some checks, it looks pretty... but wowzers -- it's big and this code is supposed to be called every time there's a REST request?


• To understand how the REST URI is mapped to the handler, read this:
• http://williamdurand.fr/2012/08/02/rest-apis-with-symfony2-the-right-way/
• Basically, it's under app/config/*.yml
• Security.yml is a good start
• Note: This is part is from symphony -- hydra demo is just returning the json-ld response...

Personally, this is way too much code baggage for something that should be much simpler to ... implement?


Extra
And, since this was mentioned in today's meeting, if you've never used this before, BOOKMARK THIS:

• http://jsbeautifier.org/
• Shove your SUPER LONG LINE here and press the magic "beautify" button