Json format is valid, but conceptually incorrect. How to argue?

Asked

Viewed 150 times

6

We recently requested a service for a partner company, to consult with some people. The service was designed from scratch to meet a particular system demand of ours. This is a simple Rest service, using JSON as return.

However, the result of the service provided caught my attention. See an example:

{
    "73317882484": {
        "nome": "Joaquim"
    },
    "55968857463": {
        "nome": "Maria"
    }
}

Although it is a valid Json, the developer understood that the CPF field would be a kind of key to group the other person’s information. So instead of him creating a field "cpf" with the value of the CPF, it adopted the CPF itself as the field name. Also, instead of creating an array for each record, a single object was returned.

Everything indicates that the returned Json has been manipulated, without any help from a framework to be generated, because it would be weird to map this Json to a Java class (for example) without knowing all the possible CPF returns. Anyway, it doesn’t make much sense.

I expected, as I mentioned before, something like this:

[
    {
        "cpf: "73317882484"
        "nome": "Joaquim"
    },
    {
        "cpf: "55968857463"
        "nome": "Maria"
    }
]

The question is: how to explain that the format mentioned before is not suitable for a return?

I did not find any kind of reference on this subject. In a brief dynamic reading by RFC I also found nothing associated with this.

json
  • 1

    Where exactly JSON is no longer appropriate?

  • 1

    In fact you can map in Java yes... What you can do is provide a documentation of the expected return and give examples

  • @Sorack, I’ve never seen this format before. It’s possible to read with Jackson? I hope you’re not talking about I also need to manipulate the Json string... rs.

  • @Andersoncarloswoss, I believe I answered your question in my question. Which point was unclear? One of the arguments is that I don’t see how it would be possible to read this in a json "parser" framework, having at the end a list of people with CPF and other information.

  • 1

    @Dherik yes, it is possible. In this case you would map this attribute to a Map<String, Pessoa> or something similar to this

  • 2

    Being a valid JSON, any Java-worthy tool to work with JSON will be able to analyze the data correctly. What I see is that maybe this isn’t the easiest way for you, so I wondered, to see if it was clear to you what the limitations were. Being clear this, your answer would be ready.

  • @Sorack, I ran a test here, it actually does. It’s just that Anderson said, it’s possible, but in my case it’s not a convenient format. Again, I had never seen this way of using Json before and immediately assumed it as "incorrect" (which is the main point of the discussion)

  • 5

    Perhaps a valid argument is semantics: to request a list of people is different from requesting a map of people. If I am interested in the whole, it makes sense that I have a list, if I am interested in insolated information, it makes more sense that I have a map.

  • Apparently it lacked scope on the integration, publish exactly the snippet that refers to the JSON that should be returned, suddenly it was requested a "valid JSON" and it was only in that that he cared. If that was the case, add the term list to the request and show an example.

Show 4 more comments

3 answers

6

Syntactically, that’s okay. But the problem here is in semantics.

The notation with {} represents an object. The notation [] represents a list.

You use this service with the intention of finding a list of people. And not an object that contains people. So if the idea is to get a list as a result, then you should have a feedback with [], and not with {}.

In addition, each person is an object (represented with {}), and in it you expect to find the relevant properties of each person, such as name, email, phone and CPF. Soon, the field cpf should be inside the object representing the person.

5


A valid argument: "73317882484" is not part of any structure. The fields in a JSON object aim primarily to reflect structure. The structure consists of names, codes (such as CPF), other fields, other objects, etc.

You might also argue, since the service was meant to be consumed by you, that simply serializing the data in a way that is not profitable to the person who deserializes it is counter-productive. There is also the problem of semantics: it is implied that the field key is CPF, not explicit.

If you were to send data like this, you might argue that a CSV would be more useful.

1

The format is not incorrect. What you can do is define a specification (JSON Style Guide) and provide to the company.

Some examples: - https://google.github.io/styleguide/jsoncstyleguide.xml - https://jsonapi.org/

Everything indicates that the returned Json was manipulated, without any help from a framework to be generated, as it would be impossible to map this Json to a Java class (for example) without knowing all possible CPF returns. Anyway, it doesn’t make sense.

This statement is incorrect. It is possible to generate/map a JSON like this.

Browser other questions tagged json

You are not signed in. Login or sign up in order to post.