---
format:
    revealjs:
        theme: simple
        chalkboard: true
        auto-stretch: false
---

## RESTful Web Services

Keith VanderLinden<br>
Calvin University

## REpresentational State Transfer

REST interfaces are guided by these principles.

- Use HTTP methods explicitly.
- Be stateless.
- Expose directory structure-like URIs for resources.
- Transfer either XML or JavaScript Object Notation.

::: {.notes}
- Use HTTP methods explicitly.
    - This takes advantage of HTTP optimizations and open Web ports.
- Be stateless.
    - Don't require the independent threads or server data needed by "stateful" transactions.
        - Illustrate this using a sequence diagram with client & server.
    - This supports scaling.
- Expose directory structure-like URIs for resources.
    - Review [URIs](https://madewithml.com/courses/mlops/api/#uri).
    - URIs should be nouns - i.e., resources. - not function names.
    - Don't mis-use the methods (e.g., using GET to update server data - GET /add-users?name=bob)
- Transfer either XML or JavaScript Object Notation (JSON) (or both?).
    - Specify these using the Mime type of the request.
:::

## Managing Data using HTTP

:::: {.columns}
::: {.column width="60%"}
The key data processing operations are:

- Create
- Read
- Update
- Delete
:::
::: {.column width="40%"}
The key HTTP methods are:

- GET
- POST
- PUT
- DELETE
:::
::::

::: {.notes}
- Draw on the slide to connect the CRUD operations with the HTTP methods used to implement them.
    - Create - POST
    - Read - GET
    - Update - PUT
    - Delete - DELETE
- To serve predictions, using POST (see [Method](https://madewithml.com/courses/mlops/api/#method)).
:::

## Operation Properties

HTTP requires that some of its methods have certain properties.

- Nullipotency
- Idempotency

These properties, if implemented properly, give benefits to Web operation.

::: {.notes}
- GET must be nullipotent (aka pure) meaning that it has no side effects.
    - Nullipotent means that running it or not running it results in the same state.
    - This allows the Web to cache the results of GET requests.
- PUT/DELETE must be idempotent
    - Idempotent means that running it once or many times results in the same state.
    - It can have side effects but performing the operation multiple times doesn't change the results.
    - This allows a client to rest easy knowing that it can resend operations that fail, without worrying about the state of the server.
- POST has no such requirements.
    - POST can change the state of the data on the server, e.g., by adding a new record with a new ID. Note that running POST multiple times will result in multiple new records with multiple new IDs.
    - We'll use POST to serve predictions.
- Note that I used the programming language examples (e.g., `a = 4`; `a++`) in the quiz, so don't review them here.

References

- <https://en.wikipedia.org/wiki/Idempotence#Computer_science_examples>
:::

## System Architecture

*See the live discussion.*

![](images/rest-architecture.png){width=55%}

::: {.notes}
- Build a deployment diagram for our system (to be implemented in the demos).
- Client (local machine)
    - Browser (Firefox): Only sends GET requests
    - CLI running cURL (WSL2): Can send our POST request to `/predict`
- Web server
    - Web Server (Uvicorn): Handles HTTP requests
    - REST App (FastAPI): Implements our REST interface
- Database server (MongoDB Atlas)
    - MongoDB
        - Database collections
- Associations
    - Browser to Web server (HTTP)
        - HTTP requests (POST)
    - Web server to Web app
        - Managed by FastAPI
    - Web app to database server (pymongo)
        - Data requests
- Show what we implement: cURL commands; REST app; DB collections (already built).
- Review why the REST interface is necessary.

References

- <https://madewithml.com/courses/mlops/api/#intuition>
- <https://github.com/kvlinden-courses/cs262/blob/master/materials/09is/monopoly-architecture.jpg>
:::
