Interface writing problem

My interface looks like this. Only when there is a return, the data in json will have a value, otherwise it will be an empty string

A colleague told me that when he received it, the data was converted into an object using json. Then if the data was empty, his entire program would explode, or my data would return null, which cannot be returned. I just don’t understand is this really the case

Reply content:

My interface looks like this. Only when there is a return, the data in json will have a value, otherwise it will be an empty string

A colleague told me that when he received it, the data was converted into an object using json. Then if the data was empty, his entire program would explode, or my data would return null, which cannot be returned. I just don’t understand is this really the case

That’s true. Your original data is an object. If it becomes an array, it will die without processing. You can $info['data'] = new stdClass();//return an empty object
as an I think the server side should be sensitive to field types.

Don’t we need to judge the code value?

Did your colleague use a framework to parse json? Just ask him to parse it manually. Don't use frames.
Otherwise the framework cannot determine that [] in data is an empty object.
Of course, you can also judge the value of the code before parsing.

This will indeed happen if the client code is not written well. The pot has been thrown to you. If you are better than him, throw it back; otherwise, take the pot. . .

Generally, clients will use a framework similar to gson to parse the json data returned by the server, and the data format needs to be defined in advance. Since data is an object, you can use the object's default value of null. I think this requirement is quite normal.

I think this is a question of who can change easily~~
I think what you said makes sense. Generally, I will take whatever convenience my colleagues give me back. Then do the processing yourself.
Of course, let’s analyze the specific issues in detail~~

I think it’s better to judge the value of code

As an API, the same field should return the same data type.
But if it solves the problem, you can also use code.
So, if you are in development, change the interface. If it is already online, change the interface.

So interface joint debugging is required

What your colleague said is no problem. Make sure that the data type of each field is always consistent. After all, are they strongly typed? Haha

The writing on the app side is not rigorous enough. It first determines the status code code. If it succeeds, it will continue to parse the data. If it is not successful, it will return the error code code and not parse it.
The server side has weak types of PHP, so the app side has a type for each data. Requirements, that is, strong typing, try to ensure the consistency of the returned data type. When data is not empty, the returned json string will be parsed by the app as an object. When data is empty, the server will determine whether it is empty. If it is empty, then Assign an empty object

<code>$obj = new stdClass();</code>

Why not define variables first on the PHP side? ? $data=array()
In addition, the client must ensure that it does not crash no matter what. I suggest that during the development process, you simulate some error return values ​​to the client to see if the client will crash, and then let He took the blame haha, you were kidding

<code class="php">$result = array(
    "code" => "2",
    "msg" => "",
    "data" => (Object)array()
);</code>

Don’t write directly

<code class="php">$result = array(
    "code" => "2",
    "msg" => "",
    "data" => array()
);</code>