cs445 - Spring 2020

Q: Do we need to develop the REST client?

A: No, you only need to implement the back-end.

Q: How do we handle access control for various actors?

A: In the interest of time you are not required to implement access control.

Q: Our project requires us to perform unit testing. This is expected for the base classes, but is it possible to perform unit testing for the REST controller?

A: If you keep your REST controller *very light*, then you don't need to do unit testing on it.

Q: The project Functional Testing says that we need to deploy the resulting .war file to a tomcat server. I want to use the open source framework DropWizard for the project that allows to deploy the RESTful service as a standalone jar application without using a tomcat server. Will that be ok?

A: Yes. Matter of fact we encourage you to use a framework such as DropWizard since that will greatly simplify the work you need to do around implementing the delivery mechanism (REST end points) and allow you to focus on implementing the core functionality for the project.

Q: Do we allow Drivers and Riders to edit the reviews they submitted?

A: Editing a review, e.g. changing the rating or adding/changing/removing some content from the review is a legit use case. We'll have to decide if its implementation is required for the project submission.

Q: May a Rider submit more than one review for a driver and ride?

A: No.

Q: Do we allow Drivers/Riders to cancel rides during/before ride in case of emergencies such as traffic accidents? Do we need to record canceled rides?

A: There is no use case to address your question, therefore the answer is No.

Q: Are we going to include payments/transactions for the rides?

A: No, the SAR wants nothing to do with money transactions between drivers and riders.

Q: Who can view the reviews between the riders and drivers? Is it the whole universe, the business owner, just people in the transaction?

A: Just like with typical ride-sharing applications, e.g. Lyft or Uber, if you have an account then you can see the overall rating of a driver/rider and the comments in the various reviews. NOTE: only the driver and the riders on a ride can see the details of the ride, such as departure and arrival points, date of the ride, etc.

Q: If there are multiple Riders on a ride, is each of them allowed to submit a review?

A: Yes, but only if they have solicited to participate in the ride independent of each other. Otherwise only the rider that contacted the driver may review the driver; likewise, the driver will provide a review for the rider that solicited the ride regardless of how many people are in the rider's party.

Q: assuming that Drivers could be Riders on future rides , and conversely that Riders could become Drivers, are the ratings for these two roles separate? For instance, does a registered account have a "driver rating" and "rider rating" or is it just one "user rating" that covers both?

A: Yes, each account has a "driver rating" and a "rider rating".

Q: I am trying to decide on the best data structure to hold the Trips/Rides, given that they need to be sortable by date, start point, and end point. I was thinking that a tree would be the best option, but I'm not sure as there are 3 different data points to sort on. Any insights would be appreciated.

A: Cardinal rule: get working software first, then you can worry about optimization. Personally I would go with the simplest possible implementation, such as a List.

I don't believe that there is anything in the requirements that speaks about sorting of any kind, though I'll admit that when searching for rides it makes sense to sort them by departure date; likewise, for accounts, it makes sense to list them sorted by name.

In any event, I would worry right now about getting the proper result set; once you have that you can always write a sort() function that can re-order the elements of that data set any way you want.

Q: I understand messages/notes are exchanged between drivers and riders and that both riders and drivers can see the full history of the messages with a link to the note. What does this link exactly entail? Is it a live link hosted on some webpage?

A: When a message is posted (POST /rides/[rid]/messages) you can imagine that the interactor dealing with the POST request would send a SMS/MMS message to the phone number of the other party involved in the message thread; the message would contain a link that accesses all messages for that ride (GET /rides/[rid]/messages).

Q: Regarding comments, are they the same thing as messages/notes or are they a completely different entity?

A: Different entities. Messages and notes are the same thing. Comments go together with the numerical rating of an account, see the sample JSON for the "Rate account" end point in the API definition.

Q: The requirements mention notifications being sent to the users' cell phones for various purposes. Do we do this through a 3rd part APIs such as Twillio?

A: This is how it would normally be done. Except that you don't have to do it for the project. It's enough to just include a sendMessage() in your code, but the function doesn't have to do anything.

Q: Would you like a time threshold of when you can post a ride? (Ex: I can create a ride 1 hour from the current time which may not be useful but is possible).

A: No threshold is needed.

Q: Anything regarding time, such as the time a ride is created, are we considering time zones? It gets tricky if we consider time zones unless I am thinking about it wrongly. The reason I am asking about this is because I want to prevent users from creating rides with a date_Time that has already passed for their timezone, but it gets tricky considering time zones of a particular user relative to other users.

A: Of course it gets tricky when it comes to date and time and the locale of various users; and then what locale are we talking about, the stated one based on account information -- which we don't have enough of for this project -- or the locale of the client for the API, something that matters when you travel in a different time zone. We're going to ignore the issue for this project and assume one big happy time zone for everyone.

Q: For the json responses you want them to be exactly like the API documentation and the Postman script right? It is because I have different names and styles for my json responses (Ex: I use a UUID generator for ids) but if you want them to be exact for the sake of simplicity when testing I can do that.

A: If your code passes the test suite then you don't have to worry. If not, then I would replace UUIDs -- which is what I would do as well -- with integers just for the sake of making testing simpler.

Q: For the amount_per_passenger key, should that be optional for creating a ride if the ride is free or would the user just have to put 0.0 for the value?

A: Must be a non-negative number, 0.0 if there is no charge.

Q: If the user has no conditions when creating a ride should the conditions key contain an empty string or should the key be optional as well?

A: Empty string is ok.

Q: What would the error response look like for creating a ride with a non existing account, particularly the detail value? I could not find it in the Postman script or within the test-data files from the project functional testing webpage.

A: Well, you couldn't find a test like this because the test suite I put together only scratches the surface of testing. It would look like this:

  {
    "type": "http://cs.iit.edu/~virgil/cs445/project/api/problems/data-validation",
    "title": "Your request data didn't pass validation",
    "detail": "This account (<aid>) doesn't exist or is not active.",
    "status": 400,
    "instance": "/rides"
  }