Using a restful API and json and necessary model encapsulation?

Looked at matrix.org for a while before the riot of open-source android

Want to write a simplified version of the official so much useless functions,

Found for a rest API design of system, using json communications, there are still using the model, I think it is complicated, the whole thing is a rest API access interface, json format is communication, don't need one more model layer, the most is when to send and receive verify whether the necessary fields,

I don't know how is everyone in the project?

CodePudding user response:

You don't think the data with the value of the entity to obtain a much more convenient than directly using Json

CodePudding user response:

More than a model, you don't feel more intuitive? Have a such a class, can indicate the fields mean, otherwise all write together more disorderly

CodePudding user response:

reference 1/f, the wind light cloud light v10 reply:

when you don't think the data with the value of the entity to obtain a much more convenient than directly using Json?

That is not a json object itself can use the method to access, and started should know format,

CodePudding user response:

reference LSCPMV reply: 3/f

Quote: reference 1/f, the wind light cloud light v10 reply:

when you don't think the data with the value of the entity to obtain a much more convenient than directly using Json?

That is not a json object itself can use the method to access, and started should know format,

But you have to do a lot of judgment

CodePudding user response:

refer to the second floor small forest (yhl) response:

one model more, don't you think more intuitive? One such a class that can indicate the meaning of the field, otherwise all write together more disorderly

And json as an object can also be bound output, have defined the meaning of json fields in document, the field name is not taken, even give you a model you have to know which field it is,

CodePudding user response:

Also, the same API success or failure, the format of the response is different also, equivalent to two model

CodePudding user response:

refer to 6th floor LSCPMV response:

also, the same API success or failure, the format of the response is different also, equivalent to spent two model

Are generally have a base class, the class definition code, massage, data, according to the code to determine solution doesn't parse the data

CodePudding user response:

It depends on your own habits, subsequent see documents, after all, less commonly, eventually to code for the final appraisal! If the document changes have no update or lost?
And are now in packaging base class, javaBean and JSON transformation framework, actually I feel better than a JSON, you can try

CodePudding user response:

And, assuming that response format changes, such as more than a field, the server is still the json format, eventually the receiver can display change, more than a model layer, at least model should be changed, also place much more needs to be changed, I know that such as gson can convert javabeans but always feel model layer seems to be no need for,

CodePudding user response:

Model do you have any need to look at your own preferences, of course, if you don't have the model and convenience of direct manipulation json, if you think that the model is easy to operate with the model, I feel the model is more convenient access field, parameter field and be clear at a glance, easy to code to read and maintain, so I basic convert json to model is used

CodePudding user response:

And, for the sake of convenience, writing time, mobile phone and web pages can be, may be written in javascript, compiled using nativescript, do not use the model layer

CodePudding user response:

Strange, CSDN phone the junction post for operating points in?

CodePudding user response:

Is strongly recommended to increase the model object
1. The first is more intuitive, all data can be directly when you write the code, "" out (bean. The getList () than json. GetJsonArray (" list") more intuitive better with faster)
2. It is not easy to mistake, if you json tools (GsonFormat) automatically generated model certainly not wrong, but hand play sometimes make you wonder life: there is a field called "orderId", for example, json, getLong (" ordreId "), json. GetLong (" orderld ") (did you see the two mistakes?)
3. You may think it don't model more quickly and easily, but if part of the change after a few months, you need to check the document again there are what data,
4. Write separate project the problem is not big, but if many people cooperation development, the others to modify your code is estimated to fall a lot of hair...
5. A bit when the json data format from inevitable, such as the background to return the "orderId" type String, but you want is long, so turn heap more strong logic; Background which day convulsions and returned to the long, then the app crash; The background suddenly returned to the null... And so on, perhaps this is the background of pan, but suddenly appear will let you