Remove the WebworkWebservice and replace it with the webwork API.

[drgrice1]

In reality the functionality of the WebworkWebservice routes is basically the same, but the WebworkWebservice package is an unnecessary layer of code for the functionality of these routes. So it is removed.

The WeBWorK::ContentGenerator::RenderViaRPC still handles the render_rpc route and its functionality is unchanged. It just doesn't go through the unnecessary layer of the WebworkWebservice package. The lib/RenderProblem.pm module is integrated directly into the WeBWorK::ContentGenerator::RenderViaRPC package.

The instructor_rpc route has been removed, and is replaced with the api routes, and the WeBWorK::ContentGenerator::InstructorRPCHandler package functionality is now in the WeBWorK::ContentGenerator::API package. The api routes are fundamentally different than the instructor_rpc route. Instead of the single instructor_rpc route that requires an rpc_command parameter, the desired API command is part of the route. So, for example, instead of using the webwork2/instructor_rpc route with the parameter rpc_command=putUserProblem you use the route webwork2/api/putUserProblem. The remainder of the parameters for each command are the same as before.

All of the api routes are implemented in the WeBWorK::ContentGenerator::API packages which are basically the previous WebworkWebservice packages. One notable difference is that each method is responsible for checking any necessary permissions required to use the route it provides. This is the same as all of the other ContentGenerator packages. There is a difference in the rendered JSON response for these routes. The server_response and result_data keys are not there at all anymore. Each route can determine what it really needs to return. Before the result_data was really what should have just been the returned data, and the server_response return value was a useless thing to return that was never used. Note that all of the methods pass through the WeBWorK::ContentGenerator::API base package, and that could render a response with the error key (if the user is not authenticated or the command is not found), and any of the API methods that provide a route can do so as well. The renderError method in the base package is a convenience for doing so. At this point all api routes require the user to be authenticated, but if we need api routes that do not require authentication (as before with the instructor_rpc route), that would not be hard to implement with some slight restructuring.

All of webwork2's usage of these routes in JavaScript has been updated. Generally the instructor_rpc route is only used by webwork2, so this change should not affect anyone else.

Part of the reason for this is that the instructor_rpc route was already not only for instructors. Students now use this route for tests to obtain the server time which ensures the remaining time displayed during a test is correct.

The plan is to eventually implement a way of saving answers during tests via an api route as well.

[somiaj]

Rendering problems in my course websites via the rpc still works in my setup and I did a few tests of the library browser and problem editor. Everything seems to work. Anything particular we should test?

[drgrice1]

In addition to problem rendering, check that the single problem grader works. The library browser also uses the API end points. The timer in the gateway quiz uses it (this is the only student usage).