1 of 33

L14. Server-Side Web Architectures + REST

CSCI 344: Advanced Web Technologies

Fall 2024

2 of 33

Announcements

  1. Tutorial 8 (React) due this Friday
  2. Homework 4 due next Friday

3 of 33

Today’s Topic

4 of 33

What’s New with Server-Side Programming

  • Building an API requires that we build a more complex web server that can actually store information and query a database.
  • Unlike when you’re writing code for a browser, when you’re writing server-side code, you can use any language you want! We will be using Python.
  • Examples of server-side frameworks include:
    • Rails, Sinatra (Ruby)
    • Guice or Spring (Java)
    • Django, Flask, or Fast API (Python)
    • Express.js, NestJS, Meteor (Node.js)
    • Laravel, Symfony (PHP)

5 of 33

Outline

  • Web Architectures
  • REST
  • Postman Activity

6 of 33

Outline

  • Web Architectures
  • REST
  • Postman Activity

7 of 33

Static Web Page

Architecture

Weeks 1-6

Tutorials 2-6

Homework 2

8 of 33

Dynamic, Client-Side Architecture

Weeks 11-13, Tutorials 7-8, HW 3-4

9 of 33

Server-Side Architecture

Weeks 14-18, Tutorials 9-11, HW 5-6

10 of 33

Two Families of Web Architectures

There are two main families of web architectures:

  • Heavy JS Front-end apps (Diagram 1 & 2)
    • Static HTML, CSS, and JavaScript files downloaded from web server
    • JavaScript queries and external data service and builds the DOM dynamically.
    • Examples: HW3-HW6, Facebook, Instagram, Pinterest, etc.
  • Heavy Back-end apps (Diagram 3)
    • The web server is running some kind of framework
    • The web server generates static HTML, CSS, and JavaScript files from data
    • Examples: WordPress, Jekyll, Wikipedia, Google Search

11 of 33

Outline

  • Web Architectures
  • REST
  • Postman Activity

12 of 33

Recall from Week 6

API → “Application Programming Interface”

A set of rules that you have to follow to interact with a piece of software

​

Web API

An API that you access via HTTP protocol. Offers a systematic way to:

  1. Create update, read, and delete resources over the internet
  2. Expose parts of your database to other people (third party clients)

​

In other words, Web APIs allow others to take advantage of resources distributed across providers, servers, organizations, etc.

12

13 of 33

Who uses Web APIs?

Everyone!

  • Allows organizations to systematically expose parts of their data / resources for authorized users to consume simply and easily.
  • How well you design your API – how easy it is to use, documentation, etc. – determines whether it gets used at all (which impacts the success of your project).
  • It’s useful to study how other companies and organizations have designed their APIs (e.g., Spotify, Twitter, Yelp, NASA, NYC Open Data Portal, etc.)
    • Learn from them!

14 of 33

Standardizing HTTP Interfaces

  • In the early days of the web, there were no standards, so everyone build their Web APIs differently.
  • This meant that each time a client wanted to interoperate with a different system, they would have to learn a new set of rules, conventions, etc.

15 of 33

A variety of different solutions to this problem

  • SOAP (1998). Simple Object Access Protocol. Developed by Microsoft. Requests to formulate queries issued via XML; can get complicated to formulate, but still used.
  • REST (2000). Representational State Transfer Protocol. Developed by Roy Fielding. Today’s topic. A very widely used approach (at this point in time).
  • GraphQL (2015). Developed by Facebook and open sourced in 2015. Allows you request more fine-grained subsets of relational resources (see docs)

16 of 33

Web APIs & the REST Architecture

One popular way of building a Web API is by following the REST architecture guidelines. Some facts about REST:

  1. REST: Stands for REpresentational State Transfer
  2. An architecture style or design criteria. Not a standard or a language
  3. Stateless, client-server, cacheable communications protocol
  4. Use HTTP requests to post, read, and delete data.
  5. Lightweight
  6. Nouns as URI, verbs as HTTP method

16

Source: https://www.slideshare.net/cebartling/rest-web-services

17 of 33

Resource-Oriented Architecture

  1. Resource-oriented�About storing, manipulating, and querying resources (nouns)
  2. Addressability �Resources are identified by URIs (which are also called endpoints)
  3. Statelessness�No connection state maintained between REST invocations
  4. Connectedness�Resources should link together in their representations
  5. Uniform interface
    1. Methods (verbs): HTTP GET, PUT, POST, DELETE, HEAD, OPTIONS
    2. HTTP status codes

17

18 of 33

1. Resource

Noun. The thing that is being represented by data / a document

  1. Can be a physical object(s) (something you buy on Amazon)�or an abstract concept (likes)
  2. Every resource has at least one name
  3. Resources can be list resources (called containers) �or detail resources:
    1. Container/List Resource: http://127.0.0.1:5000/api/posts
    2. Detail Resource: http://l27.0.0.1:5000/api/posts/6

18

Source: https://www.slideshare.net/cebartling/rest-web-services

Note the plural convention for detail resources

19 of 33

1. Resource

Example of a resource: https://<server_address>/api/posts/22

{

"image_url": "https://picsum.photos/600/430",

"user": {

"first_name": "Timothy",

"last_name": "Myers",

"username": "timothy_myers",� ...

},

"caption": "Spend catch ready administration success..."

"likes": 853

}

​

​

19

20 of 33

2. Addressability

  1. Endpoints: Every resource has an address, denoted by a URI (uniform resource identifier)
    1. Example: https://<server_address>/api/posts/22
  2. The URI enables the client to perform “CRUD” operations
    • create new resources
    • update the resource
    • read / obtain useful information about the state of a resource
    • delete the resource

20

Source: https://www.slideshare.net/cebartling/rest-web-services

21 of 33

2. Addressability: Examples

Container/List Resource (create and read):

  1. https://photo-app-secured.herokuapp.com/api/posts
  2. https://photo-app-secured.herokuapp.com/api/following �

�Detail Resource (update, delete):

  1. https://photo-app-secured.herokuapp.com/api/posts/200
  2. Note that not all container resources make their detail resources accessible

21

22 of 33

3. Statelessness

Means that there is no “stored context” or memory across transactions:

  1. Each request from the client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
  2. The client (i.e. your app) is responsible for:
    1. storing and handling all application state related information on client side
    2. sending any state information to the server whenever it is needed

22

Source: https://restfulapi.net/statelessness/

23 of 33

4. Connectedness

You should be able to connect / discover relationships between resources from the resource representation. Example (Comment):

{

"text": "Text text text....",

"post_id": 6,

"user": {

"first_name": "Emily",

"last_name": "Terry",

"username": "emily_terry",

"email": "emily_terry@gmail.com",

...

}

}

​

23

Source: https://www.slideshare.net/cebartling/rest-web-services

24 of 33

5. Uniform Interface

“Interface” — refers to the way we interact with and modify resources.

�In REST All resources are created, updated, read, and deleted in the same way, using the HTTP protocol methods (verbs), which are defined in the header of the request. Here are some of them:

  1. GET
  2. POST
  3. PUT
  4. PATCH
  5. DELETE

24

Source: https://www.slideshare.net/cebartling/rest-web-services

25 of 33

GET

Retrieves / reads a resource (or container of resources) from an address on a server

�NEVER modify a resource using the GET method – you can do it (technically) but you never should.

25

26 of 33

POST

Creates a NEW resource on a server; usually done by posting to the container endpoint:

​

26

27 of 33

PUT & PATCH

PUT: Replaces a single resource on a server

PATCH: Updates part of a resource on a server

​

27

28 of 33

DELETE

Permanently deletes a resource on a server

​

28

29 of 33

HTTP Status Codes

Use the status codes to help your client understand success and failure. Here is a list of them.

For HW1 and HW2...

  1. Use a 201 status code if POST is used to successfully create a resource
  2. Use a 200 status code for a valid request (most other requests)
  3. Use a 400 status code if user posted a bad request
  4. Use a 403 status code if a resource is forbidden (you don’t have access)
  5. Use a 404 status code if a resource cannot be found
  6. Use a 500 status code if the server encountered an error

30 of 33

References / Credits

Much of this REST overview was derived from:

RESTful Web Services�https://www.slideshare.net/cebartling/rest-web-services

  • Christopher Bartling
  • Nick Spilman
  • Kevin Hakanson

​

​

30

31 of 33

Clients

You can access a REST API via many different clients (including):

  1. Using JavaScript on a web browsers
  2. Python / Flask
  3. cURL
  4. native apps
  5. Postman (today)
  6. And more!

32 of 33

Outline

  • Web Architectures
  • REST
  • Postman Activity

33 of 33

Activity: Postman

Postman is a popular API development and testing tool. It provides a user-friendly interface for sending HTTP requests to APIs and receiving responses, making it easier for developers to build, test, and debug web APIs. To use it:

  • Register for an account
  • Use the tester to verify that your endpoints are working properly.
  • Demo:
    • Getting the Access Token
    • Using it to request protected resources
    • Noticing methods, headers, HTTP response codes, error messages, etc.

33