Good afternoon, in the project, the backend developer wants to receive requests that will be sent from the front and a response from the backend. but what he really needs to explain is apparently not capable, or does not want to. Please tell me if there are any standard practices how best to document these things and how to do this is the only thing that managed to get out while this is an example request

form_data = $("#your_form").serialize(); $.post("/_ajax.php", {token: $('#f_token').attr("content"), file: 'constructor', data: { items: ['CO037EWIRW04IN', 'CO037EWILA28IN'] tags: {id:1; id:2; } sex:1 type_body:1 color: 4 category:6 } }, function(r) { try { result = jQuery.parseJSON(r); } catch(err){ alert(err); } if (result.status == "success") { alert(result.mes); } else { alert(result.mes); } });
  • An interesting situation ... usually the backend developer determines what the API can ask, do and how to give it. Try to talk with him in the terminology of REST - the easiest option. T / e determine the resources that are present in the application (again, this is a question for the backend ... the front is the matter - it only needs to be shown correctly), determine what you can do with these resources. Well and further: POST api / v1 / posts, PUT api / v1 / posts / 1, GET api / v1 / posts, GET api / v1 / posts / 1 and m / n on the situation. - Andrei Guba
  • backeder does not recognize rest. can do only the processing of requests of a general type in the stateful version - xtfkpi
  • @xtfkpi backednd should define logic, not frontend. Otherwise, it will be a complete mess. If the front end user needs something that is not in the backend (or poorly / inconveniently implemented) - he makes a request for implementation in the backend, but how the backendors decide how to implement it. They come up with this in such a way that the front task could be performed, and the new functionality was flexible and could be used outside the scope of the task. - Goncharov Alexander
  • Well, on the front there is also a certain interaction logic. so while in the process of synchronization - xtfkpi

1 answer 1

All standards for describing web services revolve around REST or SOAP. Your case is definitely closer to REST, at least because your JSON is used to send the response. I can recommend the RAML language for which there are a lot of tools (and for the generation of documentation as well).

The fact that you do not have separate addresses for resources is not a problem at all. Anyway, there are some separate ajax methods, just agree that /path/to/action will mean something like / /ajax.php?route=path/to/action ? /ajax.php?route=path/to/action /path/to/action .

And the fact that the service is not stateless should also not prevent you from filling out the documentation in RAML notation.

I even think that with time the standard of description itself will push you to the correct part of the server part. One of the ways to use RAML, by the way, is to design an API .