This document discusses building RESTful APIs with Django. It provides a quick overview of REST principles like resources, representations, and uniform interfaces using HTTP methods. It then outlines a general approach to building REST APIs with Django by mapping URLs and views to models. Specific HTTP methods like GET, POST, PUT, DELETE are mapped to CRUD operations. Tools like Firebug and SQLite Manager are recommended for testing and viewing REST responses. Overall it provides guidance on implementing RESTful APIs in Django following best practices.
4. Practical REST
● Building a web for computers
● They (computers) want to find 'computer-friendly'
pages
● They love well organised data/information
● They don't mind about ”visual appeal”
● Side note: There is no ”Google” for them [yet].
5. REST Keywords
● Resource
● ”Resource name” or URI [or URL]
● Representation
● Methods/Verbs (Uniform Interface)
● Links
6. REST: Resource
● Any entity, object or concept we want our
application to keep information about
● Obvious resources:
● Books, people, employees, cities, blog entries, bank
accounts, hotels, flights, ..
● Slightly less obvious:
● Money transfers, hotel reservations, flight tickets, …
● Even less obvious:
● User session, transaction, ...
7. REST: Resource Name
● Every resource should receive at least one
name that identifies it uniquely in its context of
usage or existence – ideally, in the world.
● This name should be durable, persistent.
● Typical naming schemas: URLs, URIs, URNs
● It is OK to have more than one name identifying
the same resource
8. REST: Representation
● Representations are the materialization, in
bytes and bits, of resources.
● Resources are ideas, concepts; representations
are ”physical”, ”tangible” REPRESENTATIONS
of ideas
● Multiple formats possible
● A single resource can have multiple
representations associated to it
13. General Approach
urls.py
urls.py JSON
HTML
views.py
views.py
models.py
models.py
templates
14. Methods
● OPTIONS
● Should be always available with any URI
● Returns a list of available methods for that URI in the
”Allow” header of the HTTP response;
● GET
● on a collection URI returns a list of items in that collection
– for large collections, consider paging
● on an item's URI returns a representation of that item
(resource)
● ”Safe”
15. Methods (contd.)
● POST
● Points to a collection URI
● Creates a new resource in that collection
● We don't know the resource-id beforehand
● Not idempotent!
● PUT
● Points to an item URI
● We KNOW the resource-id
● Creates a new resource or updated an existing one
● Idempotent
16. Methods (contd.)
● DELETE
● Usually points to a resouce URI
● Deletes the resource
● Retry strategy is not a problem
● HEAD
● Like GET, but returns only headers, no body
● Good for retrieving information about the resource
as its size, language, content type, etc., without
transmitting the entire resource.