Due Date: July 25 before midnight;
Max Points: 100
Important Reminder: As per the course Academic Honesty Statement, cheating of any kind will minimally result in your letter grade for the entire course being reduced by one level.
To be turned in via the submission link on brightspace.
Please remember to justify all answers.
You are encouraged to use the web or the library but are required to cite any external sources used in your answers.
It may be the case that some questions cannot be answered as requested.
Design web services for supporting home sales for both sellers and buyers. The web services should support sellers creating a listing for a house as well as buyers searching for a suitable house. Your web services need not deal with:
Authentication and authorization.
Back-end storage for the details of each home.
Your answer should merely deal with the web interface to the back-end system. Your answer should describe each service, including endpoint URLs, HTTP methods, caching and errors. 15-points
Since we are designing web services, it should be clear that subsequent references to seller and buyer do not refer to people but to client software (like browsers) representing people having those roles.
A buyer will only use GET methods, whereas a seller will
have access to the full panoply of HTTP methods.
POST /api/homes: This method will be used by a seller to
create a listing. The body of the request will be a JSON
representation of standard information required for all homes
like address, asking price, floor area, number of bedrooms,
etc.
If successful, the request will record the posted information
and return a URL homeUrl for the newly created listing. This URL
may be something like /api/homes/ mls where mls is the
ID identifying the listing.
GET /api/homes: This method will be used by a buyer to
search for homes with the search terms specified by query
parameters corresponding to the standard information created
for the request. Some search parameters like price and area
may represent range queries rather than exact queries.
PUT homeUrl / resourceId : This request will be
used to associate additional information like photographs or
more details with the listing. Note that resourceId is
chosen by a seller. The body of the request will contain
the information which will be persisted.
PATCH homeUrl, DELETE homeUrl, PATCH homeUrl
/ resourceId, DELETE homeUrl /
resourceId: These services can be used by a seller to
update or remove already posted information.
GET homeUrl, GET homeUrl / resourceId:
Return the previously posted representations of the resources
accessed by those URLs.
The GET requests can be set up to cachable for a day. Since
the material is not critical or likely to change too often, the
cache should not require validation.
Incorrect URLs should result in a 404 status; incorrect parameters should result in a 400 status.
What kind of HTTP caching directives would you specify for each of the following web pages:
A blog which is updated at most once a day.
A page which only contains a search form for a library.
A page which shows the results for a library search.
A bank statement.
A page which displays the contents of a shopping cart.
You may make any reasonable assumptions. 15-points
Since the blog is updated at most once a day it seems reasonable to cache it for one day. However, since it is not known exactly when the blog is updated, it is probably a good idea to make the cache conditional. So something like:
Cache-control: public, no-cache, must-revalidate, max-age=86400
Since the basic functionality of the library search page is unlikely to change, it can probably be cached indefinitely, let's say 10 days without any revalidation.
Cache-control: public, max-age=864000
The search results can probably be cached for a while depending on how often the library's collections are updated. However the search is probably going to be repeated by a user within a few minutes, so it may make sense to cache only for a day:
Cache-control: public, max-age=864000
Since the bank statement is sensitive information it should never be cached:
Cache-control: no-cache, no-store, must-revalidate
Note that no-store should be sufficient but
MDN suggests the above.
This would depend on whether the shopping cart can be changed by a browser other than the one which may cache it. If that is the case, it is probably a good idea to make the cache conditional:
Cache-control: private, no-cache, must-revalidate, max-age=86400
A design for web services for a shopping cart hosts all the
services at the same POST url and specifies the different
services using query and/or body parameters. For example:
POST /api?fn=getItems
POST /api?fn=addItem&sku=shirt132&nUnits=3
POST /api?fn=delItem&orderItem=2
Discuss the tradeoffs for such an approach. 10-points
The advantage of this approach is that the design looks like
basic remote procedure calls, with the procedure name specified
by the fn parameter and the arguments serialized via URL-encoded
query and body parameters. This approach is familiar to most
programmers and is easily understood by programmers unfamiliar
with web technologies.
The disadvantage of this approach is that it merely uses the web as a transport mechanism and is antithetical to basic principles of web architecture.
Since all calls use POST, none of the responses can be
cached.
URLs cannot be bookmarked.
Since all kinds of requests go to the same URL, URLs are not being used to identify resources and there is no concept of a resource.
How can you ensure that an object property is hidden. Specifically,
complete the step commented TODO below:
> obj = { a: 42 }
{ a: 42 }
> obj
{ a: 42 }
> //TODO
...
> obj
{} //property a not seen
> obj.a //but it is still present
42
>
10-points
The property can be hidden by making it unenumerable, This
can be done using Object.defineProperty().
Object.defineProperty(obj, 'a', { enumerable: false });
On some older e-commerce web sites, the button which starts some kind of irrevocable action like placing an order has cautionary text saying something like Please click this button only once.
What technical detail of HTML and HTTP explains the need for this caution.
How can you remove the need for this message in modern web sites for a better user experience. 10-points
The answers follow:
It is extremely likely that the form is being submitted
using a POST request. Since POST does not provide
any idempotency guarantees, it is possible that undesired
behavior may result if the button is clicked multiple
times.
The first solution to this problem using modern technologies
is to use JavaScript within the browser to deactivate the
button as soon as it is clicked (HTML provides a disabled
attribute on form controls). Another possibility is that
JavaScript directly takes over submission of the form, cutting
out the browser form submission process. In that case, the
JavaScript could not only disable the button, but also submit
the form directly, ensuring that it is submitted just once.
REST web services can use different representations like JSON, XML or HTML. Discuss the suitability of each representation for supporting HATEOAS. You are expected to use online resources to research HATEOAS and these representations. As usual, you should reference any resources which you use in your answer. 15-points
HATEOAS requires support for links and forms.
The basic JSON format has absolutely no support for links or
forms. There are plenty of "
standards":
json reference, json-ld,
HAL,
Collection+JSON, among many. Note the last supports forms as
templates.
There are standards: xlink for external links and xptr for links within a resource and xforms.
Supports both links and forms natively within the language.
So JSON, which is currently the most popular representation for
building web services has very poor support for HATEOAS while the
least popular representation HTML has the best support. Note that
even though HTML is usually intended for human consumption, there
is no reason it cannot be used for machine consumption. It can
support structured data using <ol> for arrays and <dl> for
maps. It even supports linking in semantics using
itemscope.
An advantage of using HTML is that it is possible to use the same
representation for machines and humans (when enhanced using
stylesheets). A disadvantage is that the only supported HTTP
methods are GET and POST, but the most serious disadvantage is
that it is hardly ever used as a representation for web services.
An object obj has a secure property which contains security
information. How can you set things up so that any use of the
obj.secure property while the program is running is written into
an audit log. You are not allowed to make any changes in the code
which uses obj.secure. 10-points
Make the secure property a "virtual" property such
that any access to it triggers getter and setter functions.
Something like:
obj = {
secure_: ...,
get secure() {
auditLog(`get ...`);
return this.secure_;
}
set secure(val) {
auditLog(`set ...`);
this.secure_ = val;
}
}
Discuss the validity of the following statements. 15-points
It is possible to use the log recorded by a web server to count the number of times a particular URL has been loaded into a browser (you should assume that the web server log records the URL associated with each incoming HTTP request).
HTTP caching directives allow a resource to be correctly served from a cache even when the bits representing the resource on the origin server do not match the bits representing the resource in the cache.
Since HTTP is built on top of TCP, a separate TCP connection has to be created for each resource which is loaded by a web page.
If two JavaScript objects share the same prototype, then any update to a property of the first object will also affect the second object.
A session context in a server-side web framework can be used for storing user preferences.
The answers follow:
Because of caching, it is entirely possible that a URL was loaded into a browser without ever hitting the web server. Hence the statement is false.
Correctness may simply require a semantic match rather than a bitwise match. So for example, if only the stylesheet linked by a resource has changed on the origin server, the cached content may still be semantically equivalent to the origin content. Etags allows the server to control the meaning of what a match means and it can choose to return the same etag value for semantically equivalent content. Hence the statement is true.
This was true for HTTP 1.0 but is not true for HTTP 1.1 which supports persistent connections. Hence the statement is false.
When a property is updated in an object, the update is made only in that object, never in its prototype even if the prototype contains that property. Hence an update to an object will not affect another object which shares the same prototype and the answer is false.
The answer depends on the following:
Are the user preferences critical? That is, is it acceptable to loose the preferences.
Are there multiple application servers, each having its own session context?
Are the session contexts stored purely in memory or persistent and automatically propagated across multiple application servers?
If it is acceptable to lose the preferences, or the session context is persistent and propagated, then the statement would be true. Otherwise the statement would be false.