They don't do anything that you couldn't before, but the improve the ergonomics of Optional, much like map and flatMap. This proposal puts forth a few simple additions to Optional.
#PEEK COM API CODE#
There is a simple page at the root level of the implementation which allows all data to be wiped clean.Īlternatively, the code can be run locally using the development server provided with the App Engine Java SDK.
You will need to change the API_HOST value in the client config to point to the live instance. If you want to just try it, there is a live deployed version available here: Datastore interface (also adds caching):.Instead, more knowledge of time slot conflict could be added to the booking to boat allocation to keep larger blocks of seats available for booking. This tends to avoid conflicts like in test case 2, however, it does not always maximize the largest available booking. This implementation tries to use a boat that is already going in the timeslot availble. More efficient allocation of bookings to available boats.In case of a conflict of boat allocation as in Test Case 2, it might be better to reflect that a boat is no longer available by not returning it in the "boats" field of the timeslots response.A specific boat could then be referenced by the semantic "boats/boat-id". A POST to "boats" adds a boat, a GET reads the list of boats. For example, instead of having "boat" and "boats", just have "boats". Consider using the plural in RESTful API endpoints.Transactions should be used when modifying multiple entities that relate to one another. Q: What complications can you foresee while doing this exercise?Ī: The data model must stay consitent when bookings or assignments are made. It's possible to reduce the simulated likelyhood of this using a JVM flag, fault_high_rep_job_policy_unapplied_job_pct. This is unlikely to be a problem if API calls are being made in response to user activities vs. If running on the development server you may see this show up as "Unknown Boat" because the development server simulates some percentage of inconsistent reads and you may need to refresh the client after running through the setup. The automated "Test Case 1" setup can expose this because it adds two boats and immediately queries them. Th HRD uses an "eventually consistent" data model meaning that it's possible for a query to not "see" writes by other clients for a few seconds. There are, however, scalability benefits to this approach. This choice was made primarily to remove dependancies and allow this demo to run with minimal setup. This implementation used Google's High Replication Datastore (HRD) which is a distributed, "eventually consistent", NoSQL datastore.
Java/GAE implementation of API challenge