I am somewhat new to web development and maybe this question belongs to stackoverflow, but there is a human-interaction component here.

Here is the scenario. I am serving some neural network models via an ASGI backend server developed via fastapi and deployed via uvicorn. So far as I am concerned, the server is working perfectly, and even verified by the frontend developer from the well known fastapi swagger docs that I gave him. In addition, I gave him sample curl commands that are working as well.

Problem is, he says he cannot make the calls from his react.js script and I have no clue about that language/framework (or any frontend matter). Somehow in the manager's eyes (who is a business guy, has no clue about frontend, backend, any end) it is becoming my responsibility to develop the API in a way that frontend code can call it. I thought the whole point of a REST API was to isolate the responsibilities (and different languages, frameworks etc.) But clearly, it is not happening here.

So is there a language independent test or specification after which we can say the backend is doing its job, now it is upon the frontend to make it work? What kind of resource, or documentation can I supply to my frontend colleague to prove unambiguously the API is working as it should, without myself digging through how he calls it. I somehow believed curl commands (invoked from bash terminal) are a universally accepted specification, am I correct? I also know there are tools like postman which can make api calls, but then again, seems it will be another frontend, and even if it works, does not mean my team's frontend code will work.

What is the industry standard here, and how more successful teams (presumably handling much bigger and complicated projects) do it?

Correct me if I am making any wrong assumption here or missing some crucial detail to give the context.

  • 2
    Did your colleague include any other detail? When someone comes to you as a developer and says "X doesn't work", you always follow up with "Whats the error message that you get?" (or something else, until they tell you what the symptoms are). "Doesn't work" has nowhere in my career been a valid bug description. There is a very plausible cause for your colleagues errors (SOP, CORS), and i'd really be surprised if they only communicated "i can't" or "it doesn't work".
    – marstato
    Nov 5, 2021 at 9:21
  • 1
    cUrl working but not calls from a React app makes me think this is a CORS problem. The line between frontend and backend can get blurry at this point, and you can't really develop a separate React frontend ('separate' = 'running on a different domain than the api') without some basic knowledge of apis/CORS/etc.
    – GHP
    Nov 5, 2021 at 13:59
  • If your primary consumer is building a frontend app, then maybe generate the examples in e.g. fetch/Axios syntax rather than curl.
    – jonrsharpe
    Nov 5, 2021 at 19:14

2 Answers 2


You're making the incorrect assumption that you and your frontend colleague are adversaries. The correct way of dealing with problems at an interface is to cooperatively debug both sides.

You seem to have done a bit in that direction already by providing your colleague with working curl examples. Do they work on his development machine, too? There might be firewall issues. Can you log client/server interaction to see whether he's calling your service at all and with correct arguments?

Of course it is entirely possible that your colleague is incompetent, and then it should truly be his manager's task to find a solution, but this should only be assumed when there is undisputable evidence that the problem is with your colleague's code, and he is unable or unwilling to accept that fact. You should certainly consult another colleague who is technically competent before going that way.

So in essence, the industry standard of solving such problems is to analyze cooperatively, not to put blame on each other.

  • Thanks, and probably my post came across as more adversarial than intended. Yes, the curl examples are working from his machine, and agrees with that. But then, is there a guarantee that anything that works with curl will work with react.js unless there is some network configuration blocker or firewall etc.?
    – Della
    Nov 5, 2021 at 8:36
  • 3
    @Della React is purely a UI library designed for rendering web content in a browser, it does not specify anything at all related to how to communicate with a web server. If Curl (or Postman, or indeed any other similar HTTP tool) can send requests and read responses, then a web browser can do the same using plain simple JavaScript (and optionally any JavaScript HTTP library like axios). If your colleague is having issues getting HTTP requests working from within the browser/JavaScript then you may need to focus on what the problem is there. Nov 5, 2021 at 10:19

It would be nice to have a "industry standard" :-)

Fun aside.

CURL commands are a way to test the endpoints (the programm POSTMAN is also used quite often for the people who do not like command lines :-) ).
But they do not "define" an API, they just show examples how the API could be used. And like all examples they just show a small part of the whole.

A (not official) "standard" is the OpenAPI Specification, where you can quite clearly define and document the technically relevant things of your API.

Additionally i would think a bit about service level agreements. Because from the Frontend perspective it may make a difference in the way i implement the UI if i know that the backend may respond very slowly or may be not available quite often for some time.

  • 1
    The OpenAPI spec is the Swagger the OP's already generating with FastAPI.
    – jonrsharpe
    Nov 5, 2021 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.