You need to write a REST Web Service application that provides the database functionality (see below); and a client application (either Java or web-page-based) to show that the Web Service is working.
As in the previous coursework, your client should NOT have any kind of user interface, or need any user-input- an application that calls the service to add some sample data, and then calls it to output results is all that is required as long as it demonstrates all the features of your service. In practice, as before, there are very few marks for the client - it's just to demonstrate your service.
You need to implement the following REST Web Service methods which implement a simple database containing information about mountains, mountain ranges and countries.
1. Add a mountain - a method that adds a new mountain (a name, the mountain range it belongs to, the country that mountain range is in, it's height in metres, and it's hemisphere (Northern or Southern). For example, a REST client in Java might look like addMountain("Snowden", "Snowdonia", "Wales", 1080, "Northern"). If the country and/or mountain range do not already exist, the call should create then. If a mountain of that name, in that range and country, already exists, then your code should do something sensible.
2. Delete a mountain - remove a mountain by name, range and country (that is: you must specify all of the parameters: mountain name; mountain range; country). If there is no such mountain, again your code should do something sensible.
3. Update a mountain's height - by specifying it's name, range and country (as in 2 above) and a new height, update the height of the a mountain. For example, upDateMountain("Snowden", "Snowdonia", "Wales", 1085) - note you don't need to specify if it's in the Northern or Southern Hemisphere here. Once again, do something sensible if there is no such mountain.
4. Get mountain height by name, range, country - return the height of the named mountain, in the named country and range. Again, do something sensible if there is no such mountain.
5. Get all mountains by range and country - return all mountains in the specified country and range (the data returned should be name and height).
6. Get all mountains by country - return all mountains in the specified country (the data returned should be name and height).
7. Get all mountains by hemisphere - return all mountains in the specified hemisphere.
1. Choice of Operations. The list of methods above might seem random but it isn't - it's meant to get you to think about the choice you make of HTTP operations, and how you pass parameters. There are a significant number of marks for getting this correct.
2. Mountain Ranges and Countries. In real life, a lot of mountain ranges cross multiple countries. You can worry about this if you want, but you don't have to (and the operations above are chosen partly so you don't have to). It's not a problem to have an implementation that does not manage to work out that the Himalayas are in all of China, India, Pakistan, Nepal, Afghanistan,...
3. Consider Synchronisation. As before you should consider synchronisation BUT there are far fewer marks for that here mostly because I am assuming people will use one of the models in the sample solutions to CW1 as a basis for this, if they did not do so well last time.
4. Return Types. As before, think carefully about flexibility and usability - does the choice you have made restrict how useful your solution would be in "real life" where it won't just be called by your own client, which is essentially only meant to demo/test your service. However, this is less of an issue in this coursework because, as above, I'm expecting/hoping people learn from CW1.
5. Errors. There are a number of possible errors that can occur in the operations listed above - there is credit for handling these well.
6. Netbeans and Glassfish. You need to build and test your application either using the Netbeans-based techniques. Let me know if this is going to be an issue for you.
7. Data Persistence. There is also no need for your program to store data when it's not running - so no need for e.g. files. 8. No Complex GUIs - either "graphical" or text based. Again, no complex interfaces of any kind please - just a 'client' that showcases/tests the service.
9. Style. I'm still interested in good Java style than I was in CS-110. You will still find the material in the Appendix at the end of the course material ('modules') useful here.