RestaurantReviews

The Problem

We are in the midst of building a mobile application that will let restaurant patrons rate the restaurant in which they are eating. As part of the build, we need to develop a web API that will accept and store the ratings and other sundry data from a publicly accessible interface.

For this project, we would like you to build this API. Feel free to add your own twists and ideas to what type of data we should collect and return, but at a minimum your API should be able to:

1. Get a list of restaurants by city
2. Post a restaurant that is not in the database
3. Post a review for a restaurant
4. Get of a list of reviews by user
5. Delete a review

Additional Information

This exercise is used to help us get a better picture of how you approach and solve for a given problem. Your submission will be evaluated based on a variety of criteria including, but not limited to, product quality, demonstrated knowledge of system design and coding best practices, completeness, and ease of use from a consumer and engineering teammate perspective. The completed solution should give us a good picture of your abilities and style, so feel free to use the programming language and tools with which you are most comfortable.

Prior to submission, please fork this repository. If your solution includes code auto generated by a development tool, please use an additional commit to clearly separate it from your own work. When you have completed your solution, please issue a pull request to notify us that you are ready.

Have fun!

Implementation Notes

Starting the service

Some options to start the web app on Windows:

1. In Visual Studio, run the Restaurants.Web project in debug. This will start the service at https://localhost:44374
2. Open a command line in the RestaurantReviews.Web directory, and execute dotnet run This will compile and start the service at https://localhost:5001

The service is set up with some sample data to start with. The original is in RestaurantReviews.Web\Database\SampleReviews.db3. To start over, you can delete the copy from the runtime directory (RestaurantReviews.Web\bin\Debug\netcoreapp3.1\Database\SampleReviews.db3) and recompile/restart the service.

API

See https://localhost:/swagger/index.html for the API format and a test environment.

You can also test with a tool like Postman, but will need to disable SSL validation.

The API is primarily built around Restaurants and Reviews, and each is referenced a unique Id (Guid).

• An address with a unique Id can be used by multiple restaurants. This is because multiple restaurants might share the same building (E.g. Taco Bell/KFC combos), or a restaurant might go out of business and a new one takes its place. An address is implicitly added when a restaurant is added with a new address Id.
• A user (reviewer) with a unique Id can be used by multiple reviews. A user is implicitly added when a review is added with a new user Id. For this project, the user db is only for the display name on reviews, and not full user profiles (e.g. with emails/passwords/profile pictures/etc).

Design Notes and Disclaimers

• In an effort to deliver a working solution with a minimal learning curve, I started with what I am familiar with. I used Sqlite.NET-PCL because I am most familiar with it from professional experience. If I were doing this for a production solution and had more time, I would have probably gone with a cloud-based SQL database, or MySql, or perhaps a NoSql database like MongoDb. I'm aware this nuget is actually marked deprecated (there is a newer .NET Standard version) but there are some API differences and the older PCL version is 'tried and true'.
• I had not created a web API from scratch before, so I actually saved that part for last. I started by implementing and testing the database, and then added the controller and Web Api layers on top of it. So it was mostly a bottom-up design, and it evolved several times throughout the process. The Web Api is functional but probably does not follow best practices since that is not currently in my expertise.
• The interfaces in the core project are intended to allow for different implementations (e.g. Json-serialized vs Sql) and easier injection in unit tests.
• The controller layer is a very thin wrapper on the database. The purpose of this is to be an intermediate entrypoint for other APIs, e.g. a local UI or console app.
• I added a little sanity checking, but focused most of my time on the 'happy' cases. I did not write a complete set of unit tests for errors/etc.