In SDLC, who is responsible for ensuring that the backend API is compatible with the UI/UX?
Tester, front-end developer, software analyst, or some other role? I think that it's the responsibility of the tester. Am I right or there are any other roles?
There is no universally applicable SDLC or associated roles. Who is ultimately responsible or accountable depends on how your organization has defined roles and their associated responsibilities and accountabilities.
However, I would suggest that a person in a tester role is not responsible or accountable for ensuring that a backend API is compatible with a frontend or UI implementation. A tester would be responsible for verifying that a frontend implementation is compatible with a backend implementation, but I would look to the people who are responsible for specifying the interface and creating the implementation, and if there are two or more developers (such as one developer working on the backend and one on the frontend), I would expect that they would be expected to work together to ensure that their designs and implementations are compatible before testing begins.
You're conflating the Software Development Life Cycle (SDLC) with accountability and responsibility. While there's some overlap among them, they are really three different things. You need to distinguish between those things in a way that makes sense for both your organization and your product development framework.
In SDLC, who is responsible for ensuring that the backend API is compatible with the UI/UX?
There's no singular answer to this. SDLC—and yes, there are versions of SDLC that are iterative or incremental rather than linear—is a cradle to grave systems life cycle, so while you'll find plenty of useful information about the various stages of SDLC, you won't find a single RACI matrix or similar role chart that will hold true across every organization or even between all projects within a single organization.
Even if you put together a RACI matrix, it's important to understand there's a huge difference between accountable (who must ensure something is done) and responsible (who performs the activities that get stuff done). Furthermore, most such matrices distinguish between many forms of collaboration beyond just accountability and responsibility.
In a non-agile organization, I'd say that the role most responsible for making sure you have a front-end that works with your back-end is the application architect. Without resorting to dictionary definitions, pragmatically speaking an architect is usually the role that designs the overall system and determines how the parts are intended to fit together. They don't do this alone, though; they often work with business analysts, end users, organizational stakeholders, and engineers to determine what the optimal solutions might be.
However, you also tagged your question agile without defining a specific framework. This prevents you from using a simplistic RACI matrix because most agile frameworks have the notion of "collective ownership" of the product being built. Consider that the Principles behind the Agile Manifesto says that "good design enhances agility" and that:
[D]evelopers must work together daily throughout the project...The best architectures, requirements, and designs emerge from self-organizing teams.
So, none of the roles you named are really accountable, and by themselves are rarely responsible. In particular, testers are in no way likely to be either accountable or responsible, but are often collaborators in validating that the parts of the system are working to specification.
In an agile organization, the whole team is responsible for delivering incremental progress towards this product goal. In a more traditional organization, the project stakeholders (e.g. a project sponsor or steering committee) are ultimately accountable, although the project manager is often held accountable without the authority to do anything other than possibly influence outcomes.
While I certainly recommend the whole-team approach in an agile context, in any context I'd turn to the following skill sets (regardless of the organizational roles of the people who possess those particular skills) to be responsible for a design that works across layers:
Systems architecture skills.
Responsible for a design that works across layers.
Front-end and back-end skills.
Cross-functional skills among developers working together to build a solution that implements the design effectively between layers.
Testing skills.
The ability to validate that the system is operating as intended.
In scrum or general agile approaches, the team is collectively responsible for delivering iterative or incremental slices together. This is not a fire-and-forget approach, though; it requires frequent inspection and adaptation by both stakeholders and the project team to ensure the final product is fit for purpose.
Ensuring that the frontend and the backend are compatible is the responsibility of the testers, but of course, but coding them compatible is the responsibility of the frontend and the backend developers together.
A common theme of agile styles of working is that teams are at their best when they are cross-functional, empowered and collectively accountable for the work they deliver. A healthy team ought to be capable of pulling together to deliver a working, tested product. Assigning individual responsibility for such things may just be a sign that the team aren't working together as effectively as they could be.
