Python for Informatics Chapter 13 – Web Services (Part 2/3)



So I hope you enjoyed that
video about Doug Crockford. He's a pretty funny guy. He's got sort of an
irascible sense of humor. You can find some more
of his talks on YouTube. One of his probably
the funnest things is this picture that's
wandering around the internet. Douglas Crockford
wrote a book called JavaScript, The Good Parts. And so what we see
here, of course, is here is the book that
talks about JavaScript, The Definitive Guide, which is
everything, and then the book called JavaScript,
The Good Parts is much smaller than JavaScript,
The Definitive Guide. Part reason for
that is JavaScript is a really, really deep
and powerful language. As you've probably
seen with the video, if I've shown you the
video of Brendan Eich, he was very thoughtful when
he designed the language to seem simple on
the surface but yet be subtly complex and powerful
just under the surface. And so that's why
there's a big difference between doing JavaScript
at the light level and doing JavaScript
at an awesome level. And so as Doug mentioned, JSON,
he didn't exactly invent it. He just came up with a term
to legitimize the notion. And JSON.org describes it, and
he hasn't changed it barely at all since he came
up with the idea. And that, as he said, is
one of the charming things. So in the debate of XML versus
JSON, XML has its advantages. JSON has a lot of advantages,
and in many situations, people would push XML where JSON
would've been more appropriate. So there's a bit of a
backlash against XML, but there's still places
where XML is useful. But when you just
have two applications and they really just
want to send some lists and dictionaries
back and forth, JSON is a much better way to do it. Both applications know
what they're looking for. And so JSON represents data as
nested lists and dictionaries. This is another form of
composite data structures where before we talked
about data structures, it would say "a list"
or "a dictionary." And then we got
to the point where we had a list of tuples, which
is more of a composite data structure because it's
a data structure that within it has data structures. Well, in JSON,
we'd just go crazy. It's turtles all the way
down, as the joke says. And it really has two
basic primitive structures that are repeated over
and over and over again. And that is they map exactly
onto Python's dictionaries and Python's lists. And this particular bit of JSON
is using just the dictionary format. Of course, it's a
triple-quoted string, but the open brace
and close brace are the indication
that we are starting a JavaScript object, which
is a set of key value pairs. So this is name
matched to Chuck. It's a dictionary, comma. And then phone maps to– but
this is now another dictionary. Type matched international,
number matched to this string. And then that's the
end of this thing. And then email is another
dictionary with only one key and one value. So this is a dictionary
that contains two dictionaries within it. And so this is a
composite data structure. And much like what we
had to do with XML, we load the library
using import– import the JSON library. JSON is built into Python
in the more recent versions that we're using. And you basically
take the string data and you do JSON.loads, which
parses this and turns it into internal Python
data structures. But the difference
is unlike XML, which is this tree
structure, it actually is exactly Python
structures at this point. So this means that what we get
back in info is a dictionary. And if we want
the word "chuck"– if we want the word "chuck,"
we simply say info sub "name." So info is this outer
dictionary and the key name and the value is chuck. So it's like give
me info sub chuck. No querying, no nothing. It just is a Python dictionary
when we get it back. So if we then take
a quick look at how to get at this value right here,
well, info sub email– well, that's this bit right here. Actually, it's this
bit right here. Let me start that again. Info sub email is
this dictionary. So infor sub email is
itself a dictionary. Then we say sub hide
to go deeper into it and then this value is yes. So you see that
the JSON, there's no sort of querying or finding
or find all-ing or looking up. It's just there. And you'll also notice that
this is not nearly as self descriptive. We don't have the
less than person and all that other stuff that
gives us a clue as to what's actually going on in here. But if we know what
we're looking for– and we're just looking
for the name thing, and it's always going
to be the name thing– we just write info sub name. And so JSON really is a
very direct representation of lists and dictionaries
as a wire format. And that's why it's very,
very popular compared to XML when you really just are
sending data between two cooperating applications. Here's an example of a
list of dictionaries. And so in Python– well,
Python is the same way. JSON and Python kind
of look the same. Here we have square brackets,
just like a Python list. And the first item in this
list is this dictionary followed by that comma followed
by the second item in the list is this diction. So we have two item list. So when we parse this whole
thing using JSON.loads, we get back info is a
list of dictionaries. Because this is a
list of dictionaries. In this case, there's only
two of them in the list. Our dictionary– I mean our
list contains two dictionaries. And then each dictionary
has some key value pairs. And so de-reference
these things. Actually, I probably should
add a little example. A simple de-reference would
be info sub zero sub name. Because info is a list, sub
zero is that one right there. And then within that,
chuck is sub name. So again, this is
just Python syntax. Info is a list. Sub zero is the first
element of that list. And the thing that is the
first element of that list is a dictionary. So to look up the name
value, we do sub name. We could also take info, which
is a list– a list of two dictionaries. And now we can have a for
loop for item and info. So that means that item is going
to be an iteration variable. It's going to first
look at this and then it's going to look at that. Item is going to
be a dictionary. So we can say item sub name,
which is this bit right here. We can say item sub ID, which
is this bit right there. And item sub X, which
is that bit right there. So you just tear
these things apart. The curly brace things
turn into dictionaries and the square brace
things turn into lists. And again, like I said,
it's not as self-describing, but if you know what
it's supposed to be, then your Python code
looks really simple as you take this stuff apart. So once we have a
serialization, we use HTTP to move this
data back and forth. One application produces
data, and another application consumes data. It leads to start
a notion called a service oriented approach. And a service oriented
approach is a place where we break our applications
into multiple pieces and often run them
in multiple servers. Take something as
complex as Coursera. They have lots of servers
that do special purposes. And your user
interface that you see is pulling data from many
servers– different kinds of servers and
pulling them together. One might be a server
that tells who's registered in what courses. Another might be the
threaded discussion server. Another might be
the video server. And so what you is you
break your application into multiple services
and then you basically compose those together
to produce what seems to be an application. Another good example
of this would be airline reservation
systems that try to sell you hotel
rooms and rental cars. Well, airlines don't
have rental cars and they don't have hotel rooms. They just call a rental
car web service– a rental car service–
and a hotel room service. And they got their own data. And so somehow in this thing you
can buy a flight, a rental car, or a hotel room. And they book them by making
calls to those services. So this is called a
service oriented approach where you don't try to
build on every application to do every single thing. It does its thing
and it takes services from other applications. And when we are going
to use services, especially those that
don't belong to us– like if many airlines want to
talk to the car reservation system– they have to come up
with a standard that says, OK, if you're an airline
company and want to talk to our car reservation
system, here is a standard. These things are called APIs or
application program interfaces. So using these APIs, we can
standardize and make it easier so that by the time
it's all said and done, once our airline system talks
to one car company– car rental company– it can talk
to 50 different car rental companies. And so the act of
studying these APIs and standardizing these APIs to
make things simpler to reduce everybody's cost is an important
part of IT development. The building of standards
is an important part of IT development. As a matter of fact,
it's one of the things that I do a whole
bunch of my time. So here's a video
that gives an idea of the value of this
service oriented approach– about how we use services
across multiple parts of an application and
exchange data back and forth and then apply standards at each
of those service boundaries.

One Comment

  1. OBI JOHN said:

    tankx alot for sharing

    June 30, 2019
    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *