This is a completed final project with the Instructor Chaundry at Oregon State University. Cloud API is a 1 to many relationship between boats and loads. This project uses HTML, Javascript, Nodejs, Node, Npm, Google Cloud, Datastore, and Yaml. Documentation and Postman files reside in the root of the directory and source code resides in the "src" folder.
The goal of this assignment is similar to the previous assignment. You can use much of the same framework, but you will add pagination and a more complex relationship between entities. This time you are given an informal specification. You need to design the Restful API, create an API specification document, implement it and write a test suite for it. You will deploy your application on Google Cloud Platform using Google App Engine. You will use Datastore to store your data. Instructions
The information you will be modeling is boats and their loads (no slips in this assignment). A load can only be on one boat, but a boat can have many pieces of load. Below are examples of both boats and loads.
Example JSON responses: Boat
{ "id":"abc123", # automatically generated by Datastore
"name": "Sea Witch", #The name of the boat, a string
"type":"Catamaran", #The type of boat, power boat, sailboat, catamaran etc. a string
"length":28, #The length of the boat
"loads":[
{"id":"123abc",
"self":"https://appspot.com/loads/123abc"},
{"id":"456",
"self":"https://appspot.com/loads/456"}
], # This embedded list does NOT need to paginate.
"self":"https://appspot.com/boats/abc123"
}
Load
{ "id":"123abc", # automatically generated by the Datastore
"weight": 5, #The weight of the load
"carrier":{
"id": abc123,
"name": "Sea Witch",
"self": "https://appspot.com/boats/abc123"
}, #The boat carrying the load
"content":"LEGO Blocks",
"delivery_date": "10/18/2020" #The date the load is to be delivered
"self":"https://appspot.com/loads/123abc"
}
-
Create a boat
-
View a boat
-
View all boats This must implement pagination. It should return 3 boats per page. There must be a 'next' link to get the next page of results, unless there are no more pages of result (i.e., the last page of results shouldn't have the 'next' link).
-
Delete a boat Deleting a boat will unload any loads that were loaded on to it.
-
Create a load All newly created loads should begin unassigned to any boat.
-
View a load
-
View all loads It should implement pagination similar to view all boats, i.e., 3 loads per page and a 'next' link.
-
Delete a load Deleting a load should update the boat that was carrying it.
-
Managing loads It should be possible to assign a load to a boat. If a load is already assigned to one boat and then is assigned to another boat without first being removed, it should return a 403 status code. It should be possible to remove a load from a boat without deleting that load.
-
View all loads for a given boat This doesn't require pagination.
-
Self links All representations of resources must have self links. The link should go to the most direct location to find that resource.
You can use much of the same framework you created from the prior assignment. There are two main changes
The data model now has a many-to-one relationship.
The REST API implements pagination
For putting a load into boats you can use a route like /boats/:boat_id/loads/:load_id and the same thing when removing a load but with a different HTTP Verb. You can use any code that has been discussed during lectures in the course.
If we were using a relational database, we would have normalized the schema and stored the primary key of BOATS table as a foreign key in the LOADS table. But in a NoSQL database like Datastore, it is your choice how you model the relationship as long as your implementation supports the functionality. There is one restriction on the data model: you cannot store the self attribute in Datastore and must generate it on the fly.
You must use the API document from Assignment 3 as a guide for how to document your API. The document in available in rtf format. If you want, feel free to use the document as a starting point for your document.
In addition to what is contained in the API doc from Assignment 3, you must add a Data Model section in the API doc for Assignment 4.
This section must describe the entities you are storing in Datastore . Use the Data Model section in Assignment 3 description as a guide for this section.
We have provided you with a skeleton Postman collection. Feel free to use it and add code for testing each of the requests in the collection. However, it is not required that you use this skeleton collection. If you want to create your own collection from scratch, the skeleton collection will give you a good idea of the type of test coverage we are looking for. Also, it is also not required that your API spec must use the same URLs for the endpoints as are used in the skeleton collection. Feel free to design your URLs the way you want, as long as they conform to REST principles. If you are creating/adding your own tests, make sure to give them meaningful names. You must not hard-code ID values in your tests or you will lose substantial points E.g., don't put hard-coded values of slip_id or boat_id in your tests
You have a fair amount of flexibility in the assignment. For example, you have to decide what type of validation you want to perform on the input (you can stick to something similar to Assignment 3 or change it). You need to document your decisions, implement them and have tests to validate your implementation. If you have clarifying questions about the assignment, please ask them on Piazza so that other students may benefit from them.
You can use either Node.js or Python 3 to implement the API, which must be deployed to Google App Engine. Any exceptions to this must be pre-approved by the instructor.
You need to submit 4 files:
-
A file youronid_load.pdf that should contain the following thing The URL where your application is deployed on GCP An API specification that details Your Datastore data model All endpoints, i.e., the URL and the method Status codes that an endpoint can return Sample requests and responses for these status codes
-
A file youronid.postman_colletion.json with a Postman Collection of a test suite that demonstrates the above functionality including tests that show how invalid data is handled. In Postman, name your collection hw4_youronid. This will help with grading the assignment
-
A file youronid_postman_environment.json with the Postman Environment your Postman test suite uses. In Postman, name your environment hw4_youronid. This will help with grading the assignment. We have provide you with a skeleton Postman environment. However, it is not required that you use this environment file. It is your choice to use it or not.
-
A file youronid_load.zip that should include all the source code for your project. Please don't include node_modules or Python env in the zip file.