micro dtos

[hankwr]

We'll probably want to implement "micro" dtos for dealing with update calls

For example, rather than changing the start time of an event by posting an entire new event, we could instead ask for something like this:

public class EventTimeDTO {
        private String timezone; // used to help in parsing, can be "UTC", "GMT", "CST", "PST", etc.
        private String timestamp; // formatted string to be parsed later via CTService

        // Constructor...
        // Getters, setters...
}

Where the EventController class would have separate methods for updating the two timestamps a l

public ResponseEntity<String> updateStartTime(@ RequestBody EventTimeDTO time) {
        // processing...
        if (processFailed)
                return "Start time not updated";

        return "Start time updated to: " + time.getStartTime();
}

public ResponseEntity<String> updateEndTime(@ RequestBody EventTimeDTO time) {
        // processing...
        if (processFailed)
                return "Endtime not updated";

        return "End time updated to: " + time.getEndTime();
}

We can also do something like this for adding tags to profiles

Genre tag JSON example:

{
        "profile" : 0, 
        "name" : "FPS"
}

Platform tag JSON example:

{
        "profile" : 0,
        "name" : "XBOX"
}

and we should probably ask for a JSON list of these tags, which I think looks like this:

{
        [
                {
                        "profile" : 0,
                        "name" : "someTag"
                },

                {
                        "profile" : 0,
                        "name" : "someOtherTag"
                },

                {
                        "profile" : 0,
                        "name" : "someThirdTag"
                }
        ]
}

for a controller function

public ResponseEntity<foo> bar(@ RequestBody List<EntityDTO> entitities) {
        // Some processing
}

AFAIK "blank" fields need to be included in the JSON body (I've defaulted the ints to "0", but Strings would be defaulted to "", and then the missing fields would be filled in by the authentication token in the controller/service) or else Spring Security decides that it's an undefined Http request and blocks it with code 403, i.e. it was expecting

public ResponseEntity<foo> bar(@ RequestBody List<EntityDTO> entities) {
        // stuff
}

where entity is being automatically parsed by Spring from the JSON body of the Http request, but if the JSON body is malformed then Spring can't parse it into an EntityDTO, so the controller tries to call something like

public ResponseEntity<foo> bar(@ RequestBody List<WTFIsThat> entities) {
        // stuff
}

which, because we never actually defined it, gets nuked by Spring Security

Given the similarity of the two tag types, we will either want to sort the received tags automatically (i.e., frontend sends us any combination and then we run through a backend list of tags to figure out which field it should be sent to) or we will want to pass an enumerator in the JSON/DTO itself to signify what kind of tag it is. I think we talked about it yesterday, but we honestly might want to do the former since that limits data transmission and trickiness for frontend.

[stuja16]

Firstly, I just think that we should focus on building out base functionality still before we worry too much about updating.

To your point though, I think adding new DTOs may be far too cumbersome and complicated for what we are trying to do. I think we should maintain the the same DTOs, but there are two options for how we can process requests. Firstly, we can completely overwrite the current entry with the new DTO object (AKA delete the old one and insert the new one). This makes sense because in order to update an object, the front-end first has to get the details on it originally, so they would be in charge of replacing the fields in the DTO before sending it back. I think this makes the most sense. Secondly, we could send the full DTOs but have placeholder "blank" values (0s and ""s) for the fields that they don't want to change. Then, the functions will only replace values without the blank placeholders.

Part of the reason I don't want more DTOs is that then the number of endpoints and separate methods we need to write & test explodes, and we especially do not have time for that.

For the tags, I think using the DTOs you've already created is great, but instead of trying to sort them on the back end since they have identical formats, we should just have separate endpoints for entry. That way we don't have to do input validation against the lists like you suggested because I'm worried that would be a little clunky & require a lot of coordination. Think of post requests like this:

[baseurl]/users/profile/genretag
[baseurl]/users/profile/platformtag