Doubt about best practices for Rest API (object -> json)

Asked

Viewed 320 times

0

I have doubts about the improvements in json/object conversion between server (Rest api) and client (javascript framework). My question is in relation to objects referenced by the main entity, should I send only Ids or complete object? As an example (simple) I have the following relationship:

{
    "id":2,
    "nome":"SÃO GONÇALO",
    "cep":"24030103",
    "estado":{
                "id":1,
                "nome":"RIO DE JANEIRO",
                "sigla":"RJ"
            }
}

This structure represents the relationship between CITY and STATE. When registering a new city (POST) should I send the full "state" object or only its ID to the server? Example:

  • Sending complete "state" object (POST):
     {
            "nome":"SÃO GONÇALO",
            "cep":"24030103",
            "estado":{
                        "id":1,
                        "nome":"RIO DE JANEIRO",
                        "sigla":"RJ"
                    }
     }
  • Sending only status ID (POST):
    {
        "nome":"SÃO GONÇALO",
        "cep":"24030103",
        "idEstado": 1
     }

Which of these approaches should be followed?

Regarding queries (GET), should I return to the full status reference or just your ID? The return only ID approach has the "problem" of needing a new query (javascript) to be able to display to the user the state name.

I believe that passing only the ID in the POST is the best, not traffic unnecessary data. If it’s best to follow the ID line, which is the best practice to convert these Ids on the server to objects (need the complete object on the server to validate business before persisting)?

This was a simple example, I have models in my business where the number of references is quite large. Java work on server and angular on frontend.

  • It’s usually just the ID for reducing data traffic... so when you have tables only the ID is in them

1 answer

0

Regarding the POST, the biggest problem when sending the whole object is the consistency of data. If for example, for some reason, the state comes with the following structure:

 "estado":{
      "id":1,
      "nome": "SÃO PAULO",
      "sigla": "RJ"
  }

what to do?

We do not know if the frontend made a mistake when mounting the request, or if someone changed the request "on the arm". It also has the issue of redundant data, since only with the ID you can search for the complete reference of the object.

When we talk about a GET, history reverses itself. As you yourself mentioned, if we traffic only the ID, another request will be required to retrieve the status information.

If it is best to follow the line of the ID, which is the best practice to convert these Ids on the server to objects ?

Perform a query that returns the complete object, searching for the ID. Then apply the business rules.

  • Thank you. Would it be interesting to use Dtos for each entity? My DTO would have the Reference Ids and create DTO-to-entity converters, where these converters would load the entire object. Searching I saw an approach where the entity (@Entity) had two attributes (@Column) for the same field in the database, one of type Integer (this is persisted) and another Object (this is read only), so I realized the goal was not to create Dtos and converters.. particularly disliked the approach.

  • @Welmau, in general try not to use the entities to represent your Json, leave them with the responsibility of representing the database tables and nothing else. The ideal is as I said, to create a DTO to represent each entity and feed it with the entity’s information, in the request and Sponse. Thus you will have flexibility and less problems to maintain this code, avoiding this type of solution that you yourself mentioned.

Browser other questions tagged

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