Termipankki
  1. A
    1. API Blueprint
    2. Addressability
    3. Ajax
    4. Anonymous Function
    5. App Context
  2. B
    1. Blueprint
    2. Business Logic
  3. C
    1. CORS
    2. Callback
    3. Client
    4. Column
    5. Column Attribute
    6. Connectedness
  4. D
    1. DOM
    2. Database Schema
  5. E
    1. Element
  6. F
    1. Fixture
    2. Flask App
    3. Foreign Key
  7. G
    1. Generic Client
  8. H
    1. HTTP Method
    2. HTTP Request
    3. Header
    4. Host Part
    5. Hypermedia
  9. I
    1. Instance Folder
  10. J
    1. JSON
    2. JSON Schema
  11. L
    1. Link Relation
  12. M
    1. MIME Type
    2. Migration
    3. Model Class
  13. O
    1. ORM
  14. P
    1. Primary Key
    2. Profile
  15. Q
    1. Query
    2. Query Parameter
  16. R
    1. Regular Expression
    2. Request
    3. Request Body
    4. Request Object
    5. Resource
    6. Resource Class
    7. Response
    8. Response Body
    9. Response Object
    10. Rollback
    11. Routing
    12. Route →
      Routing
    13. Row
  17. S
    1. SQL
    2. Static Content
  18. T
    1. Table
    2. Test Setup
    3. Test Teardown
  19. U
    1. URI
    2. URL Template
    3. Unique Constraint
  20. V
    1. View Function
  21. W
    1. Web API
Ratkaistu: / tehtävää

Project implementation

During this project work the students:

Requirements overview

General requirements

During this course, the students have to design, document, implement and test a Web API, that meets REST principles, follows ROA architecture. In addition, it is recommended that the API utilizes hypermedia formats. Students must also design, implement and document a client application that uses that Web API functionality.
Hence, the final deliverable should include two fully functional pieces of software: the Web API and the client application. The client application must be able to send HTTP requests to retrieve or modify resources in the server. The Web API must process those requests and generate adequate HTTP responses. The Web API must be able to store persistent data (i.e. must contain a functional database). Figure 1 shows the general architecture of the system.
'
System architecture
Figure 1. General system architecture

Project work implementation and documentation in short

Students must deliver both projects work report as well as the software implementation by the final deadline. Exercises must also be delivered by the final deadline. Students meets twice with the course staff: one in the middle of the course and one at the end of the course to present the final version of the project.
Software of the project must be stored in a GIT repository. Students can choose among Github, Gitlab or Bitbucket. The Project Work Report must be written in a Wiki associated to the previous GIT repository. The repo structure as well as the Project Work Report section are provided by the course staff. More information in the GIT repo setup section.
GIT repo and Project Report template must be forked from the course Gitlab repo or Github repo
The documentation must be written in English.
The students are free to choose the development environment and programming language they prefer. However, the course staff only provide support for the programming languages and the web frameworks and libraries utilized during the exercises. Students who choose a different programming language or framework must configure the development environment and tools by themselves. Furthermore, they must deploy the Web API in a public server accessible by the course staff, with clear information on how to test their API.

Assessment in short

The final grade of the course depends on the quality and correctness of both the Project Work Report and the software implementation. Both, the Web API and the client application must implement basic functionality in order to pass the course. Exercises and meeting with the course staff will have also some impact on the final grade. More detailed grading information can be found from the Evaluation criteria section of this documentation.
In addition, there is a minimum set of requirements that the projects must meet in order to pass this course. They are specified in section "Minimum requirements and constraints" of this document.
Important note concerning plagiarism: Course staff will not tolerate plagiarism. If the course staff detects plagiarism the students will automatically fail the course. When students include text, XML/javascript fragments, code ... written by somebody else, they must indicate clearly the origin. It must be clear what is the student's own work and what is work created by others. The project work must contain mainly material generated by students themselves.

WorkflowProject registration

Students work individually in their projects and complete the exercises.
Each student selects its own topic. The list of topics selected by other students can be found here . By Deadline 0 , students must register here. During the registration, students must provide following information:

Setting up GIT project

All your files and your Project Report must be uploaded to a GIT hosting service. We recommend either Github, Gitlab or Bitbucket.
We have created a demo project that you must fork into your own account. We have the demo project in GitHub and GitLab. You can choose the best option for you.
Follow the next steps to setup your project:
  1. Open the URL of course project either in GitLab or Github
  2. Press the fork button at the top of the page and follow instructions
  3. Change the name of the project.
    • In GitLab go to Settings>General>Project name
    • In Github go to Settings>Repository name
  4. Clone the project in your computer. Clone URL appears at the top right corner.
    • If you want to use login and password for pulling and pushing use the HTTPS option
    • If you want to use a private key use the SSH option. You can follow instructions on how to setup a private key in Gitlab or how to setup a private key in Github.
Documentation must be written in the project Wiki:
However, when you fork the repository the Wiki is not copied. Wiki is created in an additional repository. You have two options to copy the wiki in your own project.
OPTION 1: No that much experience with GIT
What we need to do is to clone the wiki that we provide in your own computer and then move the content of this wiki to the wiki on your own Gitlab/Github project.
  1. Create a new folder in your computer, for instance name it originalproject. Clone the Wiki provided by the course staff in originalproject. Clone URLs can be found in the following links:
  2. Create a new folder anywhere in your file system. For instance name it myproject
  3. Clone in myproject the Wiki of your personal GIT project (should be currently empty). The URL is either in the Clone this wiki locally (Github) or Clone repository (Gitlab).
  4. Copy all the content from originalproject into myproject. Do not move the hidden .git folder
  5. Using the GIT bash cd to myproject.
  6. Execute the following GIT commands:
git add --all
git commit -m "Initial Commit"
git push origin master
You can now edit your Project Work Report either using the Web interface or using your local computer and pushing the changes.
OPTION 2: Some experience with Git
This option allows you synchronize with the course Wiki in case we need to do some changes during the course.
  1. Create a new folder for your Wiki. For instance, name it myproject.
  2. Clone in this folder the Wiki of your personal GIT project (It should be empty right now). The URL is either in the Clone this wiki locally (Github) or Clone repository (Gitlab).
  3. Create a new remote. You must use the URL of the course project Wiki. After that do a pull to that remote in order to copy the Project Work Report. Solve any conflicts that appear, usually in the home.md file. After that commit all changes and do a push to your own project's wiki repo. Following commands will perform these tasks.
    • In Gitlab:
git remote add pwp https://gitlab.com/programmable-web-project-/pwp-.wiki.git
git remote -v
git pull --allow-unrelated-histories pwp master
git add --all
git commit -m "Initial commit"
git push origin master

git remote add pwp https://github.com/programmable-web-project-unioulu/PWP.wiki.git
git remote -v
git pull --allow-unrelated-histories pwp master
git add --all
git commit -m "Initial commit"
git push origin master
You can now edit your Project Work Report either using the Web interface or using your local computer and pushing the changes.

Writing the report

For each section you need to complete the corresponding part of the Project Work Report in your Wiki Project. At the beginning of each page you have a short summary of what you should do during that this deliverable. After each section (heading) you have instructions on what to do in that section. Furthermore, you have detailed instructions on how are we going to evaluate that section. In the text we use the following icons:
Instructions. What to do in this section (heading)?
Detailed evaluation instructions
The pencil means that you need to write your own text in this section.
The computer means that for this section you do not need to write any text but implement software
You can edit the document using the Web editor of the online platform. In addition, you can edit it from the local version of the repository in your own computer. If you use the GIT repo you need to follow the Markdown syntax. You can find a small tutorial in the following link. Do not forget to {{commit}} and {{push}} after you have edited the document.
Some additional recommendations:
It is important to note that the documentation required in this course exceeds the documentation that you normally needs to provide when implementing a Web API / Client in "real life" (e.g. in industry). However, we require that extensive documentation to be totally sure that you understood the main concepts taught during the course.

Writing the code

Students are free to choose the structure of their software repo. It is mandatory that the root of the repo includes the README.md file with clear instructions on how to setup your environment, populate the database, run your Web API and your client, run your test scripts and any other instructions that you consider relevant for us to test your Web API and client. If you are using python it is recommended that you use the file requirements.txt with all your libraries.In addition, you must include the meetings.md file in which you must write your meeting notes.
You can create a new repository for the client (for instance, if the client is developed in a non-web platform such as Python or Android). In this case, you must still keep the Project Work Report in Wiki of the original repository. Do not create the Project Work Report in two different repositories
A recommended structure for your repo is shown in Figure 2:
'
Repo folder structrue
Figure 2. Folder structure inside the repository
When you commit a new software version to the repository it is mandatory that you write a short description of the changes that you have done in the code.
IMPORTANT: When you pull the final version of your code for a given deadline, tag this commit using the git tag command. The tag name should be the name of the deliverable: deliverable1, deliverable2, deliverable3...

Meetings with the staff

Each student has to meet at least twice with the course staff to present the current status of the project work via videoconference. We will use Adobe Connect for those meetings. During the meetings the assistants ask some questions to clarify certain concepts and give some recommendations.
After each meeting students should write meeting notes and upload them to their GIT repo. The meeting notes must include a summary of what were discussed during the meeting and a set of action points agreed with the assistant
The time reserved for each meeting is ~30 minutes. We will soon publish instructions for booking a meeting session.

Exercises

There are 4 mandatory exercises of 3 hours each. In those exercises, we present to the students some software tools, frameworks and libraries that are going to be useful for their project work. Completion of the exercises are mandatory to pass the course. The exercises list and their schedule are available in Lovelace main page. The material will be provided via Lovelace platform. The course staff might also propose some test/readings that students have to complete/read before coming to the exercises. Students will be informed via mail in such cases.
Exercises topics are:
.
Please, keep an eye to the exercises schedule in Lovelace main page. It might change along the course

Minimum requirements and constraints

Students can use any programming language both for the RESTful API and for the client application. BUT:
The minimum requirements to pass the course are:

RESTful API

Client application

Evaluation criteria

The final grade of the course is mainly based in the quality of the project work. Other aspects, such as the performance in the lab exercises, active participation during the meetings with the assistants are also taken into consideration. We emphasize quality vs quantity: that is, it is more important that you have a small API (small number of resources) which has a proper design following RESTful principles, with adequate documentation and tests that covers your whole application than implementing an application which contains a large amount of resources but badly documented and tested.
In general, students who do all the exercises, agree a meeting with the assistant and CAREFULLY follow all the instructions for the project report, get a final grade of at least '3'.Students fail the course automatically if plagiarism is detected in any of the deliverables.
When we assess the report, we take into consideration its quality and its conformance with the specifications provided in the project report. Evaluation criteria for each section is provided in the Project Work Report.
Table 1 summarizes how the course is evaluated. Table 2 shows which will be your final grade (0 to 5) based on the number of points you got during the course (out of 100).
Project Work Topic Deadlines Number of points (out of 100) [*]
RESTful API description D1 8
Database design and implementation D2 10
RESTful Web Service API design D3 25
RESTful Web Service API implementation D4 19
Client design and implementation D5 15.5
Analysis and reflection D6 4.5
Project managment - 3
Exercises, meeting and participation - 15
Table 1. Evaluation.
Point (out of 100) Final Grade
< 51 0
51 - 60 1
61- 70 2
71 - 80 3
81 -90 4
> 90 5
Table 2. Final Grade.
The final grade is obtained by adding up the grade for each one of the topics. Students must get at least the 51 points out of 100 to pass the course. If you miss a deadline, you lose the corresponding points.
Each exercise (Exercise 1 to Exercise 4) will be evaluated from 0 to 3. We will consider the participation during the exercise session and the correctness of the exercise. A student cannot pass the course till Exercise 1, 2, 3 and 4 are delivered.
Extra work might increase your final grade. At maximum you can earn 15 points out of 100 by doing extra work. Extra work points count only if students meet the pass criteria (at least 60 points from table 1) .

Topics examples

We always recommend that you choose a project that might be useful for you in the future. Or at least, to implement a project related to some of your hobbies. For instance, in the past, we have had several groups of students interested in Frisbee - golf. We have had several projects related to this topic: from a system to track the score in a game to another system to store the position of different tracks and difficulty of each one of them. Other teams has implemented some software that would help in the management of their guilds: for instance to track the borrowed material to the guild members.
Here is a list of selected past projects. Please, note that many of those projects had very reduced functionality, but they were enough to complete the course.

2018

2017

Extra Work

Students can do some extra work to improve the final grade. Documentation related to the extra work must be included in the final version of the report. Before starting any extra work task, students should explain their plans to the course assistants, so they can evaluate if it can be considered as extra work. Extra work must be presented to the assistants when it is finished, so students must agree a meeting with them. Examples of tasks that can be considered as extra work are:
Students should only consider the Extra Work when they have finalized the basic course requirements. That means, for example, that students should not consider authentication while designing the RESTful API.

Deadlines

FINAL DEADLINE FOR ALL STUDENTS TO DELIVER THE PROJECT WORK AND ALL THE EXERCISES IS 10.05.2019

Disclaimer

Information contained in this document could change during the course. Any significant change to this document will be announced by through an email using Weboodi email service. The upper right corner of the page show the last changes performed to the document.

Questions?

For further questions or clarifications:
?
API Blueprint is a description language for REST APIs. Its primary categories are resources and their related actions (i.e. HTTP methods). It uses a relatively simple syntax. The advantage of using API Blueprint is the wide array of tools available. For example Apiary has a lot of features (interactive documentation, mockup server, test generation etc.) that can be utilized if the API is described in API Blueprint.
Another widely used alteranative for API Blueprint is OpenAPI.
Addressability is one of the key REST principles. It means that in an API everything should be presented as resources with URIs so that every possible action can be given an address. On the flipside this also means that every single address should always result in the same resource being accessed, with the same parameters. From the perspective of addressability, query parameters are part of the address.
Ajax is a common web technique. It used to be known as AJAX, an acronym for Asynchronous Javascript And XML but with JSON largely replacing XML, it become just Ajax. Ajax is used in web pages to make requests to the server without a page reload being triggered. These requests are asynchronous - the page script doesn't stop to wait for the response. Instead a callback is set to handle the response when it is received. Ajax can be used to make a request with any HTTP method.
  1. Kuvaus
  2. Examples
Anonymous functions are usually used as in-place functions to define a callback. They are named such because they are defined just like functions, but don't have a name. In JavaScript function definition returns the function as an object so that it can e.g. passed as an argument to another function. Generally they are used as one-off callbacks when it makes the code more readable to have the function defined where the callback is needed rather than somewhere else. A typical example is the forEach method of arrays. It takes a callback as its arguments and calls that function for each of its members. One downside of anonymous functions is that they function is defined anew every time, and this can cause significant overhead if performed constantly.
  1. Kuvaus
  2. Example
In Flask application context (app context for short) is an object that keeps tracks of application level data, e.g. configuration. You always need to have it when trying to manipulate the database etc. View functions will automatically have app context included, but if you want to manipulate the database or test functions from the interactive Python console, you need to obtain app context using a with statement.
Blueprint is a Flask feature, a way of grouping different parts of the web application in such a way that each part is registered as a blueprint with its own root URI. Typical example could be an admin blueprint for admin-related features, using the root URI /admin/. Inside a blueprint, are routes are defined relatively to this root, i.e. the route /users/ inside the admin blueprint would have the full route of /admin/users/.
Defines how data is processed in the application
Cross Origin Resource Sharing (CORS) is a relaxation mechanism for Same Origin Policy (SOP). Through CORS headers, servers can allow requests from external origins, what can be requested, and what headers can be included in those requests. If a server doesn't provide CORS headers, browsers will browsers will apply the SOP and refuse to make requests unless the origin is the same. Note that the primary purpose of CORS is to allow only certain trusted origins. Example scenario: a site with dubious script cannot just steal a user's API credentials from another site's cookies and make requests using them because the APIs CORS configuration doesn't allow requests from the site's origin. NOTE: this is not a mechanism to protect your API, it's to protect browser users from accessing your API unintentionally.
Callback is a function that is passed to another part of the program, usually as an argument, to be called when certain conditions are met. For instance in making Ajax requests, it's typical to register a callback for at least success and error situations. A typical feature of callbacks is that the function cannot decide its own parameters, and must instead make do with the arguments given by the part of the program that calls it. Callbacks are also called handlers. One-off callbacks are often defined as anonymous functions.
Piece of software that consumes or utilizes the functionality of a Web API. Some clients are controlled by humans, while others (e.g. crawlers, monitors, scripts, agents) have different degree of autonomy.
In databases, columns define the attributes of objects stored in a table. A column has a type, and can have additional properties such as being unique. If a row doesn't conform with the column types and other restrictions, it cannot be inserted into the table.
  1. Kuvaus
  2. Common keywords
In object relational mapping, column attributes are attributes in model classes that have been initialized as columns (e.g. in SQLAlchemy their initial value is obtained by initializing a Column). Each of these attributes corresponds to a column in the database table (that corresponds with the model class). A column attribute defines the column's type as well as additional properties (e.g. primary key).
Connectedness is a REST principle particularly related to hypermedia APIs. It states that there for each resource in the API, there must exist a path from every other resource to get there by following hypermedia links. Connectedness is easiest to analyze by creating an API state diagram.
Document Object Model (DOM) is an interface through which Javascript code can interact with the HTML document. It's a tree structure that follows the HTML's hierarchy, and each HTML tag has its own node. Through DOM manipulation, Javascript code can insert new HTML into anywhere, modify its contents or remove it. Any modifications to the DOM are updated into the web page in real time. Do note that since this is a rendering operation, it's very likely one of the most costly operations your code can do. Therefore changing the entire contents of an element at once is better than changing it e.g. one line at a time.
Database schema is the "blueprint" of the database. It defines what tables are contained in the database, and what columns are in each table, and what additional attributes they have. A database's schema can be dumped into an SQL file, and a database can also be created from a schema file. When using object relational mapping (ORM), the schema is constructed from model classes.
In HTML element refers to a single tag - most of the time including a closing tag and everything in between. The element's properties are defined by the tag, and any of the properties can be used to select that element from the document object model (DOM). Elements can contain other elements, which forms the HTML document's hierarchy.
In software testing, a fixture is a component that satisfies the preconditions required by tests. In web application testing the most common role for fixtures is to initialize the database into a state that makes testing possible. This generally involves creating a fresh database, and possibly populating it with some data. In this course fixtures are implemented using pytest's fixture architecture.
  1. Kuvaus
  2. Creating DB
  3. Starting the App
This term contains basic instructions about setting up and running Flask applications. See the term tabs "Creating DB" and "Starting the App". For all instructions to work you need to be in the folder that contains your app.
In database terminology, foreign key means a column that has its value range determined by the values of a column in another table. They are used to create relationships between tables. The foreign key column in the target table must be unique.
For most hypermedia types, there exists a generic client. This is a client program that constructs a navigatable user interface based on hypermedia controls in the API, and can usually also generate data input forms. The ability to use such clients for testing and prototyping is one of the big advantages of hypermedia.
HTTP method is the "type" of an HTTP request, indicating what kind of an action the sender is intending to do. In web applications by far the most common method is GET which is used for retrieving data (i.e. HTML pages) from the server. The other method used in web applications is POST, used in submitting forms. However, in REST API use cases, PUT and DELETE methods are also commonly used to modify and delete data.
HTTP request is the entirety of the requets made by a client to a server using the HTTP protocol. It includes the request URL, request method (GET, POST etc.), headers and request body. In Python web frameworks the HTTP request is typically turned into a request object.
Headers are additional information fields included in HTTP requests and responses. Typical examples of headers are content-type and content-length which inform the receiver how the content should be interpreted, and how long it should be. In Flask headers are contained in the request.headers attribute that works like a dictionary.
Host part is the part of URL that indicates the server's address. For example, lovelace.oulu.fi is the host part. This part determines where (i.e. which IP address) in the world wide web the request is sent.
In API terminology hypermedia means additional information that is added on top of raw data in resource representations. It's derived from hypertext - the stuff that makes the world wide web tick. The purpose of the added hypermedia is to inform the client about actions that are available in relation to the resource they requested. When this information is conveyed in the representations sent by the API, the client doesn't need to know how to perform these actions beforehand - it only needs to parse them from the response.
Instance folder is a Flask feature. It is intended for storing files that are needed when running the Flask application, but should not be in the project's code repository. Primary example of this is the prodcution configuration file which differs from installation to installation, and generally should remain unchanged when the application code is updated from the repository. The instance path can be found from the application context: app.instance_path. Flask has a reasonable default for it, but it can also be set manually when calling Flask constuctor by adding the instance_path keyword argument. The path should be written as absolute in this case.
  1. Kuvaus
  2. Serializing / Parsing
JavaScript Object Notation (JSON) is a popular document format in web development. It's a serialized representation of a data structure. Although the representation syntax originates from JavaScript, It's almost identical to Python dictionaries and lists in formatting and structure. A JSON document conists of key-value pairs (similar to Python dictionaries) and arrays (similar to Python lists). It's often used in APIs, and also in AJAX calls on web sites.
JSON schema is a JSON document that defines the validity criteria for JSON documents that fall under the schema. It defines the type of the root object, and types as well as additional constraints for attributes, and which attributes are required. JSON schemas serve two purposes in this course: clients can use them to generate requests to create/modify resources, and they can also be used on the API end to validate incoming requests.
  1. Kuvaus
  2. Common MIME types
MIME type is a standard used for indicating the type of a document.In web development context it is placed in the Content-Type header. Browsers and servers the MIME type to determine how to process the request/response content. On this course the MIME type is in most cases application/json.
Database migration is a process where an existing database is updated with a new database schema. This is done in a way that does not lose data. Some changes can be migrated automatically. These include creation of new tables, removal of columns and adding nullable columns. Other changes often require a migration script that does the change in multiple steps so that old data can be transformed to fit the new schema. E.g. adding a non-nullable column usually involves adding it first as nullable, then using a piece of code to determine values for each row, and finally setting the column to non-nullable.
  1. Kuvaus
  2. Example
In ORM terminology, a model class is a program level class that represents a database table. Instances of the class represent rows in the table. Creation and modification operations are performed using the class and instances. Model classes typically share a common parent (e.g. db.Model) and table columns are defined as class attributes with special constuctors (e.g. db.Column).
Object relational mapping is a way of abstracting database use. Database tables are mapped to programming language classes. These are usually called models. A model class declaration defines the table's structure. When rows from the database table are fetched, they are represented as instances of the model class with columns as attributes. Likewise new rows are created by making new instances of the model class and committing them to the database. This course uses SQLAlchemy's ORM engine.
In database terminology primary key refers to the column in a table that's intended to be the primary way of identifying rows. Each table must have exactly one, and it needs to be unique. This is usually some kind of a unique identifier associated with objects presented by the table, or if such an identifier doesn't exist simply a running ID number (which is incremented automatically).
Profile is metadata about a resource. It's a document intended for client developers. A profile gives meaning to each word used in the resource representation be it link relation or data attribute (also known as semantic descriptors). With the help of profiles, client developers can teach machine clients to understand resource representations sent by the API. Note that profiles are not part of the API and are usually served as static HTML documents. Resource representations should always contain a link to their profile.
In database terminology, query is a command sent to the database that can fetch or alter data in the database. Queries use written with a script-like language. Most common is the structured query language (SQL). In object relational mapping, queries are abstracted behind Python method calls.
  1. Kuvaus
  2. Example
Query parameters are additional parameters that are included in a URL. You can often see these in web searches. They are the primary mechanism of passing arbitrary parameters with an HTTP request. They are separated from the actual address by ?. Each parameter is written as a key=value pair, and they are separated from each other by &. In Flask applications they can be found from request.args which works like a dictionary.
  1. Kuvaus
  2. Examples
Regular expressions are used in computing to define matching patterns for strings. In this course they are primarily used in validation of route variables, and in JSON schemas. Typical features of regular expressions are that they look like a string of garbage letters and get easily out of hand if you need to match something complex. They are also widely used in Lovelace text field exercises to match correct (and incorrect) answers.
In this course request referes to HTTP request. It's a request sent by a client to an HTTP server. It consists of the requested URL which identifies the resource the client wants to access, a method describing what it wants to do with the resource. Requests also include headers which provide further context information, and possihby a request body that can contain e.g. a file to upload.
  1. Kuvaus
  2. Accessing
In an HTTP request, the request body is the actual content of the request. For example when uploading a file, the file's contents would be contained within the request body. When working with APIs, request body usually contains a JSON document. Request body is mostly used with POST, PUT and PATCH requests.
  1. Kuvaus
  2. Getting data
Request object is related to web development frameworks. It's a programming language object representation of the HTTP request made to the server. It has attributes that contain all the information contained within the request, e.g. method, url, headers, request body. In Flask the object can be imported from Flask to make it globally available.
in RESTful API terminology, a resource is anything that is interesting enough that a client might want to access it. A resource is a representation of data that is stored in the API. While they usually represent data from the database tables it is important to understand that they do not have a one-to-one mapping to database tables. A resource can combine data from multiple tables, and there can be multiple representations of a single table. Also things like searches are seen as resources (it does, after all, return a filtered representation of data).
Resource classes are introduced in Flask-RESTful for implementing resources. They are inherited from flask_restful.Resource. A resource class has a view-like method for each HTTP method supported by the resource (method names are written in lowercase). Resources are routed through api.add_resource which routes all of the methods to the same URI (in accordance to REST principles). As a consequence, all methods must also have the same parameters.
In this course response refers to HTTP response, the response given by an HTTP server when a request is made to it. Reponses are made of a status code, headers and (optionally) response body. Status code describes the result of the transaction (success, error, something else). Headers provide context information, and response body contains the document (e.g. HTML document) returned by the server.
Response body is the part of HTTP response that contains the actual data sent by the server. The body will be either text or binary, and this information with additional type instructions (e.g. JSON) are defined by the response's Content-type header. Only GET requests are expected to return a response body on a successful request.
Response object is the client side counterpart of request object. It is mainly used in testing: the Flask test client returns a response object when it makes a "request" to the server. The response object has various attributes that represent different parts of an actual HTTP response. Most important are usually status_code and data.
In database terminology, rollback is the cancellation of a database transaction by returning the database to a previous (stable) state. Rollbacks are generally needed if a transaction puts the database in an error state. On this course rollbacks are generally used in testing after deliberately causing errors.
  1. Kuvaus
  2. Routing in Flask
  3. Reverse routing
  4. Flask-RESTful routing
URL routing in web frameworks is the process in which the framework transforms the URL from an HTTP request into a Python function call. When routing, a URL is matched against a sequence of URL templates defined by the web application. The request is routed to the function registered for the first matching URL template. Any variables defined in the template are passed to the function as parameters.
In relational database terminology, row refers to a single member of table, i.e. one object with properties that are defined by the table's columns. Rows must be uniquely identifiable by at least one column (the table's primary key).
SQL (structured query language) is a family of languages that are used for interacting with databases. Queries typically involve selecting a range of data from one or more tables, and defining an operation to perform to it (such as retrieve the contents).
In web applications static content refers to content that is served from static files in the web server's hard drive (or in bigger installations from a separate media server). This includes images as well as javascript files. Also HTML files that are not generated from templates are static content.
In database terminology, a table is a collection of similar items. The attributes of those items are defined by the table's columns that are declared when the table is created. Each item in a table is contained in a row.
In software testing, test setup is a procedure that is undertaken before each test case. It prepares preconditions for the test. On this course this is done with pytest's fixtures.
In software testing, test teardown is a process that is undertaken after each test case. Generally this involves clearing up the database (e.g. dropping all tables) and closing file descriptors, socket connections etc. On this course pytest fixtures are used for this purpose.
Universal resource identifier (URI) is basically what the name says: it's a string that unambiguously identifies a resource, thereby making it addressable. In APIs everything that is interesting enough is given its own URI. URLs are URIs that specify the exact location where to find the resource which means including protocol (http) and server part (e.g. lovelace.oulu.fi) in addition to the part that identifies the resource within the server (e.g. /ohjelmoitava-web/programmable-web-project-spring-2019).
  1. Kuvaus
  2. Type converters
  3. Custom converters
URL template defines a range of possible URLs that all lead to the same view function by defining variables. While it's possible for these variables to take arbitrary values, they are more commonly used to select one object from a group of similar objects, i.e. one user's profile from all the user profiles in the web service (in Flask: /profile/<username>. If a matching object doesn't exist, the default response would be 404 Not Found. When using a web framework, variables in the URL template are usually passed to the corresponding view function as arguments.
In database terminology, unique constraint is a what ensures the uniqueness of each row in a table. Primary key automatically creates a unique constraint, as do unique columns. A unique constraint can also be a combination of columns so that each combination of values between these columns is unique. For example, page numbers by themselves are hardly unique as each book has a first page, but a combination of book and page number is unique - you can only have one first page in a book.
  1. Kuvaus
  2. Registering
View functions are Python functions (or methods) that are used for serving HTTP requests. In web applications that often means rendering a view (i.e. a web page). View functions are invoked from URLs by routing. A view function always has application context.
Interface, implemented using web technologies, that exposes a functionality in a remote machine (server). By extension Web API is the exposed functionality itself.