Friday, June 27, 2014

web nerdz

Subject: web nerdz

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


Many moons ago, I wrote the "http fun with telnet" post.


I think it needs to be revisited due to the renewed interest in 'standardized' REST calls (what web nerds say, "the way it was meant to be done")...


PUT vs POST

First, there's usually been some confusion with how REST calls are used --- in particular PUT vs POST.


Here are examples of what I mean:


But, really, a create/updating request should be thought of 'same thing'.


Note: PUT and DELETE are normally not enabled on all web servers



Server side processing

Because PUT and DELETE are quite dangerous if not controlled, server side processing (PHP, ASP, etc.) handled much of the PUT/DELETE (i.e. create, update, destroy) processes by incorporating them with AJAXy APIs (normally done with GET and POST only).


Let's see an example of the "server side processing" that a lot of people are used to:

Here, the action parameter is descriptive, to the point and clear on intention.


I do realize that the URL "parameters" are much more descriptive than 'PUT'...
  • But, you'll need to see what is 'implied' when using GET/PUT/POST...



Idempotent Retries

There's a very important concept for web server technologies that needs to be understood before continuing



Pretty URLs

A lot of web nerds want to slim down the URL so that search engines can "crawl" your web site with impunity.


Anyways, back to the implied usage of GET/PUT/POST/DELETE (what they call HTTP verbs). Let's take a look at an example URI:
  • http://webserver/account/nick
    • GET would return my details
    • PUT could update my details
    • A first time POST would create my account
    • And of course, DELETE would disable or nuke my account
  • Note that each of the methods does different things while the URL stays the same

You can still use server side processing to handle this
  • For example, in: http://webserver/account/
    • The index page has been setup as "app.php"
    • app.php will process (for example) /account/nick as the ARGs for the script (and any POST or URL parameters) to handle the request

  • you can look at (http_fun_with_telnet) and add handlers for PUT and DELETE to complete this homework assignment

Tuesday, June 24, 2014

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

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.



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
  • 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


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:
  • 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:


Thursday, June 19, 2014

json-ld (part 2 of 3)

Subject: json-ld (part 2 of 3)

  • note: originally emailed 06/19/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 3



This message is primarily for the TO: peeps. But some of you have asked about json-ld before and this would benefit everyone here for future reference.


Epiphany:
While reading up on some (computer) graphics articles -- I found out (in a round-about way) what linked-data (um, actually) the * description languages would be good for.

Not so fast:
First, why I still think it's not needed (in the context of javascript's json handler) -- it's unused information (you'll see this in a sec).
  • For more info on why I don't like json-ld (just like why I don't like VM's) -- it's heavy with a lot of un-needed cruff (you can read more about it from the email thread below).
    • Again, I'm coming from a javascript coder [for a project with restricted and security considerations] point of view...

So, what is it good for?
It (linked-data/interface description language/data format description language/etc.) is good for:
  • binary only data (i.e. structs/class)
    • getting transported between different programming languages
    • which might be running on different architecture (endian-ness, 32 vs 64 bits, etc.)
  • these (the data payload) are quite specific and can lead to catastrophic behavior if not handled properly

Examples of this type of mechanisms are:
  • ZeroC's Ice
  • Apache's Thrift
  • Google's Protocol Buffer
  • etc...

What does all that mean?
Basically, it's good for defining your data structs without (sort of) knowing anything about them.

Here's what I mean. Back to the graphics article I mentioned before. Blender (3D) is an open source modeler that had its beginnings 20 years ago.

The creator of that program made his binary data files with "encoded types for the entire internal structure" -- in other words, self-describing and included in the data file. The intention was to make it backwards compatible knowing that future versions of the program will always require inevitable changes to the data file format.

Why strike linked-data and call out the * description languages
Back to "unused information" I mentioned earlier, [for our system] -- the LD stuff will NEVER be used (I can pretty much say that now with 99.9% certainty).
  • C/C++/java/etc. however, would HUGELY benefit from a self-describing struct/class object.


So when I started to play with:

I said to myself, "this is interesting -- but what is this good for?"" -- I even said ([in part 1]):
  • this terse way of representing all of the data [is] highly error prone if written by humans -- this will need to be generated with tools just to be safe

The playground only showed results for JSON-LD and an RDF item.
  • But, there seems to be a number of possible representation for the same dataset:
  • I thought to myself, there has got to be a better way to create this (remember: highly error prone if written by humans)


Then, the following showed up in [redacted] (today in fact!):
  • [link redacted]
  • They mentioned hive-json
    • This showed how a json ld-ish output was created from (in this case) the apache hive schema

So, out of curiosity, I thought if there were other ways to help write json-ld via converters?