Re-organize ETS2MP API

[jackrv]

I think it's important:

1.1

Suggestion Name: Place all possible error descriptions

Suggestion Description: Most APIs have option "error" and hidden option "descriptor" (when error = true). I'd like to see all possible descriptions for each of your APIs.

Any example images: -

Why should it be added?: Because it is useful to know all the possible exceptions!

1.2

Suggestion Name: Add option ban_counts(Ex.) to player API

Suggestion Description: Add new option to api.ets2mp.com/player/<id>/

Any example images: -

Why should it be added?: This innovation will reduce the number of queries. If the user does not have locks, there is no reason to request the API_Ban

 

I think it's not so important:

2.1

Suggestion Name: Open main theme for posting new messages

Suggestion Description: Need open theme [FOR WEB DEVELOPERS] REST API documentation. or create new theme for dev's communicate

Any example images: -

Why should it be added?: I believe that the forum theme should be a place for developers to communicate

2.2

Suggestion Name: Add option game_time to servers API

Suggestion Description: I do not understand why did not do this initially...

Any example images: -

Why should it be added?: Because it is an extra request, which can be avoided by aligning with the server API

2.3

Suggestion Name: Change type of option "error" to boolean

Suggestion Description: Now on servers_API (https://api.ets2mp.com/servers/) option "error" has is string

Any example images: -

Why should it be added?: For beauty =)

[Guest]

1.1, we are planning major work on the api which will make most current implementations incompatible, when this is done we will also provide a library that raises the correct exceptions based on the error.

1.2, we'll consider that for future versions

 

2.1, I've been thinking about having a more developer oriented forum or mailing list, but this has been put on the backburner due to other major projects which are nearing their end now.

2.2, game_time is primarily an internal api for syncronization of the servers' times, it's documented as a curtsey to you and to minimize the response required for the time sync.

2.3, this is something that will be ammended with the api rewrite in 1.1. It's been bugging me too, but we don't want to change that due to certain implementation may be sensitive to it being a string.

[jackrv]

Thanks TuxyQ for fast reply! I would like to add , before the release of a new version of the API.

 

Suggestion Name: Add option steamID64 as string type to user API
Suggestion Description: Add one more parameter in addition to the existing. ex. steamID64_string or etc.
Any example images: See example on jsfiddle

Why should it be added?: JavaScript (and maybe some other languages) not have native support big integer Values. To use this option you must write the bikes , adding one option would eliminate many of the headaches

 

 

And, I don't understand what is happening now with your API's

See demo on jsfiddle and this screenshots:  

[ShawnCZek]

/Moved to Website Suggestions

 

Accepted, we will look things that have not been fixed or implemented.

Though, 2.3 cannot be easily done as it can break a lot of existing applications. Thus, we will most likely leave this for the next rewrite of the API.

[Jeroen]

We have created new API documentation, which was published last month. You can find it here: https://truckersmp.com/developers/api We hope this helps. 

 

// Done