This is the data service application for the CS 262 Lab 8 Monopoly Project, which is deployed here:
It has the following read data route URLs:
/a hello message/playersa list of players/players/:ida single player with the given ID
It is based on the Lab 9 tutorial from CS 262 at Calvin University, and adopts its sample Monopoly service file.
The database is relational with the schema specified in an sql/ sub-directory
and is hosted on ElephantSQL. The database server,
user and password are stored as Azure application settings so that they aren’t
exposed in this (public) folder.
We implement this sample service as a separate repo to simplify Azure integration; it’s easier to auto-deploy a separate repo to Azure.
Answers to the lab questions:
- What are the (active) URLs for your data service?
- Which of these endpoints implement actions that are idempotent? nullipotent?
- The "players" endpoints are both idempotent and nullipotent, as is the empty '/' endpoint, for "get." Put and delete are also idempotent.
- Is the service RESTful? If not, why not? If so, what key features make it RESTful.
- The service is RESTful because it:
- uses HTTP,
- does not store client states,
- has directory-style URIs specified by '/',
- and conveys information in JSON format.
- The service is RESTful because it:
- Is there any evidence in your implementation of an impedance mismatch?
- There isn't significant evidence of impedance mismatch, as every Player record can be accessed as a JSON object whose attributes correspond to those of the tuples that would originally define the Player relation.