INTERNET OF THINGS
TYBSC IT- SEM V
UNIT III
Ms. Anuja Narvekar
CHAPTER 7:
PROTOTYPING ONLINE
COMPONENTS
• API
• MASHING UP APIS
• SCRAPING
• LEGALITIES
• WRITING A NEW API
• CLOCKODILLO
• SECURITY
• IMPLEMENTING THE API
• GOING FURTHER
• REAL TIME REACTIONS
• POLLING AND CONNECT
• OTHER PROTOCOLS
• MQTT
• EXTENSIBLE MESSEGING AND PRESENCE PROTOCOL
• CONSTRAINED APPLICATIO PROTOCOL
API & MASHING UP
APIS
• The most important part of a web service, with regards to an Internet of
Things device, is the Application Programming Interface, or API.
• An API is a way of accessing a service that is targeted at machines
rather
than people.
• Perhaps the data you want is already available on the Internet but in a form
that doesn’t work for you?
• The idea of “mashing up” multiple APIs to get a result has taken off and can
be used to powerful effect.
API
• SCRAPING
• Screen scraping is the process of collecting screen display data from one
application and translating it so that another application can display it.
• In many cases, companies or institutions have access to fantastic data but don’t
want to or don’t have the resources or knowledge to make them available as an API.
• This is normally done to capture data from a legacy application in order to display it
using a more modern user interface.
• LEGALITIES
• Screen-scraping may break the terms and conditions of a website.
• For example, Google doesn’t allow you to screen-scrape.
• Alternative sources of information often are available.
• For example, you could use OpenStreetMap instead of Google Maps.
WRITING A NEW API: POMODORO
(CLOCODILLO)
• You plan to assemble the data from free or licensed material you have and process it.
• The process of building your own API is explained with an example project, Clockodillo.
• This is an Internet of Things device that Hakim (Author of Designing of Internet of Things) built to help
him use the Pomodoro time management technique
• The technique uses a timer to break down work into intervals, traditionally 25 minutes in length,
separated by short breaks.
• These intervals are named pomodoros, the plural in English of the Italian word pomodoro (tomato)
(the tomato-shaped kitchen timer).
• connecting the kitchen-timer to the Internet to make the tracking easier while keeping the simplicity of
the physical twist-to-set timer for starting the clock and showing progress as it ticks down.
• Clockodillo is an Internet-connected task timer.
• The user can set a dial to a number of minutes, and the timer ticks down until completed.
• It also sends messages to an API server to let it know that a task has been started, completed, or
cancelled.
SECURIT
• How Y
important security is depends a lot on how sensitive the information being
passed is and whether it’s in anyone’s interest to compromise it.
• For Clockodillo, perhaps a boss might want to double-check that employees
are
using the timer.
• Or a competitor might want to check the descriptions of tasks to spy what your
company is working on.
• Or a competitor might want to disrupt and discredit the service by entering
fake
data.
• If the service deals with health or financial information, it may be an even more
attractive target.
SECURITY: CLOCKODILLO
• The request
CASE has to pass details to identify the user,
which is the problem of identity; that is, the application
needs to know for which user to create the timer so
that the user can retrieve information about it later.
• But the application should also authenticate that
request.
• A password is “good enough” authentication for
something that isn’t hypersensitive.
• You have to consider the risks in sending the
identification or authentication data over the Internet
• If the username and password are in “clear text”,
they can be read by anyone who is packet
sniffing.
SECURITY: TWO
SCENARIOS
• Someone who is targeting a specific user and has access to that person’s wired or (unencrypted) wireless
network.
• This attacker could read the details and use them (to create fake timers or get information about the user).
• Someone who has access to one of the intermediate nodes.
• This person won’t be targeting a specific device but may be looking to see what unencrypted data passes by, to see what will
be a tempting target.
• If a software password is compromised, a website can easily provide a way of changing that password.
• But while a computer has a monitor and keyboard to make that task easy, an Internetconnected device
may
not.
• So you would need a way to configure the device to change its password—for example, a web control panel
hosted on the server or on the device itself.
• This solution is trickier (and does require the machine to have local storage to write the new password to).
• One obvious solution to the problem of sending cleartext passwords would be to encrypt the whole request,
SECURITY: CLOCKODILLO CASE
(REVISED)
STANDARDS TO CONSIDER FOR
IMPLEMENTING THE API
• An API defines the messages that are sent from client to server and from
server to client.
• You can send data in whatever format you want, but it is almost always
better to use an existing standard because convenient libraries will exist for
both client and server to produce and understand the required messages.
• Here are a few of the most common standards that you should consider:
• 1) Representational State Transfer (REST):
• Access a set of web URLs using HTTP methods such as GET and POST.
• The result is often XML or JSON but can often depend on the HTTP content-type
negotiation mechanisms.
STANDARDS TO CONSIDER FOR
IMPLEMENTING THE API
• 2) JSON-RPC:
• JavaScript Object Notation (JSON), is a way of formatting data so that it can be easily
exchanged between different systems.
• Remote Procedure Call (RPC) is a term to describe ways of calling programming
code which
isn’t on the same computer as the code you are writing.
• Access a single web URL like http://timer. roomofthings.com/api/, passing a JSON string such
as
• {‘method’:’update’, ‘params’: [{‘timer-id’:1234,‘description’:’Writing API chapter for book’}], ‘id’:12 }.
• The return value would also be in JSON like {‘result’:’OK’, ‘error’:null, ‘id’:12}.
• 3) XML-RPC: This standard is just like JSON-RPC but uses XML instead of JSON.
• 4) Simple Object Access Protocol (SOAP):
• This standard uses XML for transport like XMLRPC but provides additional layers of
functionality, which may be useful for very complicated systems.
PARAMETERS TO CONSIDER
ON A PLATFORM FOR YOUR
WEB BACK END
• What do you already know (if you are
planning to develop the code
yourself)?
• What is the local/Internet recruiting
market
like (if you are planning to outsource)?
• Is the language thriving? Is it actively
developed? Does it have a healthy
community (or commercial support)?
Is there a rich ecosystem of libraries
available?
• Ex: Back-end Code in Perl
PARAMETERS TO CONSIDER
ON A PLATFORM FOR YOUR
WEB BACK END
• Ex: USING CURL TO TEST
• While you’re developing the API, and
afterwards, to test it and show it off,
you need to have a way to interact
with it.
• You could create the client to interface
with it at the same time.
• Curl simply makes an HTTP request
and prints out the result to a terminal.
GOING FURTHER : API RATE
LIMITING
• If the service becomes popular, managing the number of connections to the
site becomes critical.
• Setting a maximum number of calls per day or per hour or per minute might
be useful.
• You could do this by setting a counter for each period that you want to limit.
• Then the authentication process could simply increment these counters and fail
if the count is above a defined threshold.
• The counters could be reset to 0 in a scheduled cron job.
• Software application can easily warn users that their usage limit has been
exceeded and they should try later.
GOING FURTHER : INTERACTION
VIA HTML
• The API currently serializes the output only in JSON, XML, and Text formats.
• You might also want to connect from a web browser. Not every Internet of Things product needs a browser
application.
• Perhaps the API is all you need, with maybe a static home page containing some documentation about how to
call the API.
• Drawbacks:
• Although web browsers do speak HTTP, they don’t commonly communicate in all the methods.
• Web browsers don’t commonly support PUT and DELETE.
• They support only GET and POST.
• As a solution we can “tunnel” the requests through a POST.
• There is a convention in Perl to use a field called x-tunneled-method, which you could implement like this:
GOING FURTHER : DESIGNING A WEB
APPLICATION FOR HUMANS
• Figure shows a static login page.
• This page is entirely for the convenience of a
human.
• All the labels like “Your email address” and the
help text like “Remember your password is case
sensitive” are purely there to guide the user.
• The logo is there as a branding and visual look
and feel for the site.
REAL-TIME
REACTIONS
• To establish an HTTP request requires several round-trips to the server.
• There is the TCP “three-step handshake” consisting of a SYN (synchronise) request
from the client, a SYN-ACK from the server to “acknowledge” the request, and finally an
ACK from the client.
• Although this process can be near instantaneous, it could also take a noticeable amount
of time.
• If you want to perform an action the instant that something happens on your board, you
may have to factor in the connection time.
• If the server has to perform an action immediately, that “immediately” could be nearly a
minute later, depending on the connection time.
• For example, with the task timer example, you might want to register the exact start time
from when the user released the dial, but you would actually register that time plus the
time of connection.
REAL-TIME REACTIONS:
•
POLLING
If you want the device or another client to respond immediately, how do you do that?
• You don’t know when the event you want to respond to will happen, so you can’t make the request to
coincide with the data becoming available.
• Consider these two cases:
• The WhereDial should start to turn to “Work” the moment that the user has checked into his office.
• The moment that the task timer starts, the client on the user’s computer should respond, offering the
opportunity to type a description of the task.
• The traditional way of handling this situation using HTTP API requests was to make requests at regular
intervals. This is called polling.
• You might make a call every minute to check whether new data is available for you.
• However, this means that you can’t start to respond until the poll returns.
• You could make this quicker, polling every 10 seconds, for example.
• But this would put load on the following:
• The server: If the device takes off, and there are thousands of devices, each of them polling regularly,
you will have to scale
REAL-TIME REACTIONS:
COMET
• Comet is an umbrella name for a set of technologies developed to get around the
inefficiencies of polling.
• Long Polling (Unidirectional)
• starts off with the client making a polling request as usual.
• However, unlike a normal poll request, in which the server immediately responds with an
answer, even if that answer is “nothing to report”, the long poll waits until there is
something to say.
• This means that the server must regularly send a keep-alive to the client to prevent the
Internet of Things device or web page from concluding that the server has simply timed
out.
• Long polling would be ideal for the case of WhereDial: the dial requests to know when
the next change of a user’s location will be.
OTHER PROTOCOLS: MQ
TELEMETRY TRANSPORT
• MQTT is a lightweight messaging protocol, designed specifically for
scenarios where network bandwidth is limited.
• It was developed initially by IBM but has since been published as an
open standard, and a number of implementations, both open and closed
source, are available, together with libraries for many different
languages.
• Rather than the client/server model of HTTP, MQTT uses a publish/
subscribe mechanism for exchanging messages via a message broker.
• Rather than send messages to a pre-defined set of recipients, senders
publish messages to a specific topic on the message broker.
• Recipients subscribe to whichever topics interest them, and whenever
a new message is published on that topic, the message broker
delivers it to all interested recipients.
• This makes it much easier to do one-to-many messaging, and also
breaks the tight coupling between the client and server that exists in
HTTP.
EXTENSIBLE
MESSAGING AND
PRESENCE PROTOCOL
• Another messaging solution is the Extensible Messaging and Presence
Protocol, or XMPP (http://xmpp.org).
• This is both a blessing and a curse: it is well understood and widely
deployed, but because it wasn’t designed explicitly for use in embedded
applications, it uses XML to format the messages.
• This choice of XML makes the messaging relatively verbose ("using more
words than necessary".) which could preclude (prevent from happening;
make impossible) it as an option for RAM-constrained microcontrollers.
CONSTRAINED APPLICATION
PROTOCOL
• The Constrained Application Protocol (CoAP) is designed to solve the same classes of
problems as HTTP but, for networks without TCP.
• There are proposals for running CoAP over UDP, SMS mobile phone messaging.
• CoAP draws many of its design features from HTTP and has a defined mechanism to proxies
to allow mapping from one protocol to the other.
THANK YOU!
