2

I am developing a blog website, for each post, it has a list of tags, just like stackoverflow.

There is no doubt that in the server side, i will expose a api like blog/edit to the client side, and the request parameter like:

class BlogEditParam{
    private List<String> tags;
}

So definitely i need to validate the tags field in the server side, like checking whether if the tag name exist or not, i have no doubt with that.

However, the tags field has "set" semantic, it cannot have any duplication. for example, a post cannot have a tag list like: c++, java, c++

What should i do when dealing with the possible duplication in the input parameter? It seems to me that i have two strategy:

  1. just silently ignore it. For the example i've shown above, i remove all the duplication in the server side and accept this request(of course, the c++ and java tag must pass the exist validation)
  2. report an error to the client side when finding such duplication

What's the prefer way in this blog application scenario?


I am using Spring Boot as the server side framework. It use jackson to deserialize the request body, i know i could write the input parameter like:

class BlogEditParam{
    private Set<String> tags;
}

But in fact, it just ignore the duplication when do the deserialization, so just like the first strategy that i've mention above.

1

But what if someone in the front-end decides to send hundreds, thousands, or millions of these duplicated tags all at once?

Can you handle it? (On both sides?)

Imho, the easiest way for handling this is to make it so that, for example, the user interface in the front-end, uses a "chip-like" entry of data for these tags, that can come from a dropdown or whatever, and you keep all the tags in the front-end in a set-like structure, or, better yet, allow for "click once, delete" semantics on the tags, such that, if a user adds C++, it won't even be a possible option again.

There are many ways to handle this, but, imho, the aim should be to reduce the burden of traffic across the network.

Prepare and sanitize and validate your data as much as possible in the front-end.

6
  • But should the server side should always keep skepticism attitude towards the request parameter? Of course we can do many validation operation in the client side, use the user interface design like you provide, but it doesn't mean that we should not do the validation in the back-end. Feb 5 '20 at 14:28
  • I did not say that the validation server-side should be skipped. In fact, it still needs to be done to ensure a proper design, and well, sanitization and data preparation on the frontend gives no guarantees about the state of the server. Server-side validation should be done ALWAYS. :) But what I suggested was that, if you gear your users gently towards a better design in the UI, the burden for server side validation is also lower Feb 5 '20 at 14:36
  • I totally agree your opinion, but the problem here is actually how to do the server-side validation(which strategy) Feb 6 '20 at 10:54
  • Sure, but, the validation on the server-side is simple: Validate a set of tags entered by the user, to ensure that all the tags exist, and, if you want/wish, filter out dups if you do not send a set across. If you find any inconsistency, throw a big and loud error, since it can lead your code flows down unexpected paths otherwise. Feb 6 '20 at 10:59
  • So you mean just like the first strategy that i've mentioned in the initial post, accept the tags as set and silently remove all the possible duplication? Feb 6 '20 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.