云计算代写 | CS 346 (Fall 20): Cloud Computing

这个作业是用cgi脚本完成restful api
CS 346 (Fall 20): Cloud Computing

2 What You Must Turn In
Turn in all of the CGI scripts that you use. As before, do not turn in anything
that contains passwords!
If you want, it’s possible to implement this entire project in a single Python
script – using PATH_INFO to match all of the possible paths. However, if you
want to do this, make sure to put each different operation into a function, to
keep your code cleaner!
In addition to your CGI script(s), turn in a README.txt file, which indicates
where your website is; make sure to leave it online, so that the TA can test it
out.
3 Post / Redirect / Get
POST operations are dangerous. By definition, they are supposed to change
the state of the website. This means that, if a user does a POST and views the
resulting page, if they reload the page, they are (in effect) asking the website to
perform the action a second time. This used to be a big problem on the web!
Nowadays, we have a better solution. Now, when a user performs a POST,
websites rarely give a 200 status. Instead, they give a 302 Redirect status:
Status: 302 Redirect
Location: http://mywebsite.com/other_page
When a browser encounters 302 Redirect, it immediately bounces to the
new page. It doesn’t wait for the user; it doesn’t show any message; it simply
jumps to the new page. On the new page, the browser always does a GET
operation.
(Note that the Location field of the Redirect can include CGI parameters.
Some websites make use of this; many do not.)
When the browser does a GET on the new page, we (normally) expect to
see the new page to complete with 200 status. This isn’t required (another
redirection is possible), but it’s common.

3.1 What the HTTP Server Sees
It’s important to note that the server does NOT see a direct link between
the two requests. The POST (which was Redirected) and the GET (which
2
was not) are treated as completely separate requests! Of course, a savvy
programmer, looking at the logs, could make a connection – but your code
cannot!
This means, for instance, that you cannot expect CGI variables to carry over
from the POST to the GET; if there are some CGI variables that you need, then
you must encode them in the Location field that you send when you do the
Redirect.
3.2 What This Means For This Project
Starting with this project, any time that you implement a website which supports POST operations, you must use the Post/Redirect/Get style. That is,
for this project and all that follow it, you must never return a 200 status from
any POST operation!
And yes, the same is true for all PUT and DELETE operations, as well!
3.3 Implementing it in Your Code
In practice, this means that the code path for the POST operation must be
silent. That is, it must interact with the database, make whatever changes it
wants to make, commit them, and then (at the very end) print out a Redirect
status.
This can make it hard to debug your code! But Python makes this (relatively) easy with try/except blocks. Try wrapping your POST code as follows:
try:
… put your POST logic here …
… it can span many lines …
… if you want, you can use ’assert’ statements to look for bugs …
… when your code is done with the changes: …
conn.commit()
print(“Status: 302 Redirect”)
print(“Location: some_path_somewhere”)
print()
except:
# Python will send you here if any exception (including a failed
# assert) fires. We want to report that this is an HTML page, and
# then cause cgitb to print out the pretty debug info
print(“Status: 200 OK”)
print(“Content-Type: text/html”)
print()