Digital Solutions

Unit 4: Digital impacts

Topic 1: Digital methods for exchanging data
Topic 2: Complex digital data exchange problems and solution requirements
Topic 3: Prototype digital data exchanges
This TLAPS is under constant reviewdocx

REpresentational State Transfer (aka REST) ARCHITECTURAL STYLE (for server applications) – good for speed in development, pretty URLs, and flexibility when handling data requests and mutations. This makes it easily scalable, usable and independent of other services.

REST relies on representations via a 'uniform' (think: clean and sensical) interface (e.g. addcity/Cairns/?population=170000), and stateless communication (transfer) between client and server.

Stateless communication: each request must contain all of the information necessary to be understood by the server, as the server isnt storing any session information about the client (read the KFC example underneath).

In a REST application, if I (the client) request Tuesday's roster from my work host KFC (server), I can't then send a request for just the 'next' days roster, because the KFC REST server isn't tracking what day i'm looking at. Therefore it can't know what 'next' is.

A better way for this application to provide this functionality and still conform with REST constraints would be to deliver me both Tuesday's roster as well as explicit URI's to access the resource containing Wednesday's roster (one day after).

Additionally, if i was a manager, the server may also deliver me a representation of all people working Tuesday, with enough URI's for me to edit or delete (manipulate) these shifts.

It can be argued that server side sessions used to authenticate a client violate the stateless constraint of REST. There are many ways around this (read this), with the basic premise being that each new client request supplies required credentials (through authentication token / header).

What is a RESTful API?
• Uniform Interface (e.g. uniquely identifiable through a single URL: API/rosters/Tuesday/remove/?shift=Night&employee=Baz)
• Stateless (see discussion above)
• Cacheable (do you want responses saved by client? for how long? performance vs stale data)
• Client-Server ... obviously
• Layered System (if you are delivering markup or other web services, keep these separate)
• Code on demand (optional so not a requirement of REST) - most of the time servers will send back JSON or XML, but sometimes they may send executable code (we won't be in this course so don't worry about this).

Why use REST design and not SOAP protocol to make an API? Since all these Digital Solution units sit within a web context, we can harness HTTP to deliver APIs that adhere to REST constraints (known as RESTful APIs)

Elements of an API:
  • API key
  • URI
  • Resources

develop a simple API that responds to HTTP requestions, packages data from a Python dictionary and delivers this as JSON data

more JSON files in Python examples.

IA3 sample only:
IA3 Project - folio - 25% | pdf | docx | rtf

Qld wildlife data API

Mapbox API

IA3 sample only:
IA3 Project - folio - 25% | pdf | docx | rtf

Brisbane City Council Live Event Feeds

Department of Transport and Main Roads - Developers and data | Queensland Traffic API Specification