This is part of the Java Developer course from Yandex. Module - standard Java library and its features.
The repository contains my solution that has been verified from the reviewer to the task described below.
Back to work on the task manager. The main logic of the application has been implemented, now you can make an API for it. You will have to configure access to the manager's methods via HTTP requests.
You need to implement an API where the endpoints will correspond to calls to the base methods of the TaskManager
interface. Matching endpoints and methods is called mapping. This is how it should look like.
First, add the Gson library to the project to work with JSON. Next, create the HttpTaskServer
class, which will listen to port 8080 and accept requests. Add the FileBackedTaskManager
implementation to it, which can be obtained from the 'Managers utility class. After that, you can implement mapping of requests to methods of the 'TaskManager
interface.
The API should work so that all requests along the path /tasks/<resources>
come to the TaskManager
interface. The path for normal tasks is /tasks/task
, for subtasks — /tasks/subtask
, for epics — /tasks/epic'. It will be possible to get all tasks at once on the path
/tasks/, and to get the history of tasks on the path
/tasks/history`.
To get data, there must be GET requests. To create and modify — POST requests. To delete — DELETE-requests. Tasks are transmitted in the request body in JSON format. The task id should be passed as a request parameter (separated by a question mark).
As a result, a separate endpoint should be created for each method of the TaskManager
interface, which can be called over HTTP.
There are several ways to check the API.
- Via Insomnia.
- Using a browser plugin, for example, RESTED, Postman, RestClient or others. You can select and download the appropriate one by link.
- In IDEA via HTTP request templates — scratch file. Press the combination `CTRL+SHIFT+ALT+Insert' and select HTTP Request.
Now the tasks are stored in files. We need to transfer them to the server. To do this, write an HTTP client. With it, we will move the storage of the manager's status from files to a separate server.
The server template is located in the repository — https://github.com/praktikum-java/java-core-bighw-kvserver. Tilt it and move it to the project class KVServer
. In the [Main] class(http://Main.java ) see an example of how to start the server correctly. Add the same code to your project. In the example, the server starts on port 8078, if necessary, this can be changed.
Hint: how the KVServer server works
'KVServer' is a storage where data is stored according to the principle. He can:
- `GET /register' — register the client and issue a unique access token (authentication). This is necessary so that the storage can work with several clients at once.
POST/save/<key>?API_TOKEN=
— save the contents of the request body associated with the key.GET/load/<key>?API_TOKEN=
— return stored values by key.
You need to add the implementation of the request load()
— this is the method that is responsible for receiving data. Finish the logic of the server by comments (comments can then be removed). After that, start the server and check that getting the value by key works. For initial debugging, you can make requests without authorization using the DEBUG code.
To work with the repository, you will need an HTTP client that will delegate method calls to HTTP requests. Create the KVTaskClient
class. It will be used by the HttpTaskManager
class, which we will write soon.
When creating KVTaskClient
, consider the following:
- The constructor accepts the URL to the storage server and registers. During registration, a token (API_TOKEN) is issued, which is needed when working with the server.
- The
void put(String key, String json) method
should I save the state of the task manager via the requestPOST /save/<key>?API_TOKEN=
. - The
String load(String key)
method should return the status of the task manager via the 'GET/load/' request?API_TOKEN=`.
Next, check the client code in main
. To do this, run KVServer
, create an instance of `KVTaskClient'. Then save the value under different keys and check that the required data is returned when requested. Make sure that if you change the value, then when you call it again, it will return not the old one, but the new one.
Now you can create a new implementation of the TaskManager
interface — the HttpTaskManager
class. It will inherit from `FileBackedTasksManager'.
The HttpTaskManager
constructor will have to accept the URL to the KVServer
server instead of the file name. Also HttpTaskManager
creates a KVTaskClient
from which you can get the initial state of the manager. You need to replace the stateful calls in the files with a client call.
At the end, update the static method getDefault()
in the utility class Managers
so that it returns `HttpTaskManager'.
The verification code in Main.main
has stopped working. This happened because Managers.getDefault()
now returns a new implementation of the task manager, and it cannot work without starting the server. You need to fix it.
Add the launch of KVServer
to Main.main
and restart the manager usage example. Make sure everything is working and the status of the tasks is now stored on the server.
Now you can add tests for HttpTaskManager
in the same way as they did for FileBackedTasksManager
, the only difference is, instead of checking the recovery of the manager's state from the file, the data will be restored from the 'Kvserver' server.
Write tests for each HttpTaskServer
endpoint. In order not to add the launch of KVServer
and HttpTaskServer
servers every time, you can implement a separate method in classes with tests. Mark it with the annotation @BeforeAll
— if servers are supposed to run for all tests, or with the annotation @beforeach
— if a separate launch is required for each test.
Hurray! Now our application is available via HTTP and can store its state on a separate server! You're doing great!