RESTful Web Services

Keith VanderLinden
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.

• 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.
  • 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

The key data processing operations are:

• Create
• Read
• Update
• Delete

The key HTTP methods are:

• GET
• POST
• PUT
• DELETE

• 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).

Operation Properties

HTTP requires that some of its methods have certain properties.

• Nullipotency
• Idempotency

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

• 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.

• 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