如何在Eclipse Che上基于其REST API构建自定义前端?
Great question! I’ve built custom frontends on top of Eclipse Che’s REST API a few times, so let me break down exactly how to approach this—from understanding the API foundation to deploying your finished frontend.
Eclipse Che’s backend is entirely built on RESTful APIs, which means every core feature (workspace management, project operations, plugin lifecycle, user settings, etc.) is exposed via standardized HTTP endpoints. Your custom frontend will essentially act as a client that interacts with these APIs to replicate or extend Che’s native UI functionality.
A huge help here is Che’s built-in OpenAPI documentation. Once your Che server is running, you can access it at http://<your-che-server-url>/swagger—this page lists every API endpoint, its request/response formats, authentication requirements, and even lets you test calls directly in the browser. It’s your go-to reference for all API interactions.
Before diving into code, make sure you have these ready:
- A running Eclipse Che instance (local deployment, Kubernetes-based, or Che hosted on a cloud provider—just ensure you can reach its API endpoint)
- Frontend development tools: Pick any framework you’re comfortable with (React, Vue, Angular) or even vanilla JavaScript/HTML/CSS
- Basic familiarity with REST API concepts (HTTP methods, request headers, authentication tokens)
- A valid Che authentication token: You can generate a personal access token via Che’s user settings, or capture the token from Che’s native login flow (more on this later)
Step 1: Explore and Test the API
Start by playing around with Che’s Swagger docs to get a feel for how endpoints work:
- Navigate to
/swaggeron your Che server - Browse API groups like
workspace,project,devfile, orplugin - Use the "Try it out" button to test calls (e.g.,
GET /api/workspaceto fetch your workspaces) — you’ll need to paste your authentication token into theAuthorizationheader field (format:Bearer <your-token>) - Note down the endpoints you’ll need for your frontend’s core features (e.g., starting/stopping workspaces, creating projects)
Step 2: Set Up Your Frontend Project
Initialize a frontend project with your tool of choice. For example, with React:
npx create-react-app che-custom-frontend cd che-custom-frontend
Install an HTTP client library to simplify API calls (axios is a popular choice):
npm install axios
Create a config file (e.g., src/config.js) to store your Che API base URL:
export const API_BASE_URL = 'http://<your-che-server-url>/api';
Step 3: Handle Authentication
Che’s APIs require valid authentication, so you’ll need to manage tokens in your frontend:
- Option 1 (Production-friendly): Redirect users to Che’s native login page. After successful login, Che will return a token that you can store in
localStorageor a secure cookie for subsequent API calls. - Option 2 (Testing-only): Use a personal access token generated from Che’s user settings. Hardcode this token temporarily (never do this for production!) to skip the login flow during development.
Add an axios interceptor to automatically attach the token to every API request:
import axios from 'axios'; import { API_BASE_URL } from './config'; const apiClient = axios.create({ baseURL: API_BASE_URL, }); // Attach auth token to all requests apiClient.interceptors.request.use((config) => { const token = localStorage.getItem('che-auth-token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); export default apiClient;
Step 4: Implement Core Features
Let’s build a simple workspace list component as an example. Create src/components/WorkspaceList.js:
import React, { useEffect, useState } from 'react'; import apiClient from '../apiClient'; const WorkspaceList = () => { const [workspaces, setWorkspaces] = useState([]); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { const fetchWorkspaces = async () => { try { const response = await apiClient.get('/workspace'); setWorkspaces(response.data); } catch (err) { setError('Failed to load workspaces. Check your token and API URL.'); console.error('API Error:', err); } finally { setLoading(false); } }; fetchWorkspaces(); }, []); if (loading) return <div>Loading your workspaces...</div>; if (error) return <div className="error">{error}</div>; return ( <div className="workspace-list"> <h2>My Che Workspaces</h2> <ul> {workspaces.map((workspace) => ( <li key={workspace.id}> <h3>{workspace.name}</h3> <p>Status: <strong>{workspace.status}</strong></p> {/* Add buttons to start/stop workspaces using POST /workspace/{id}/start or /stop */} </li> ))} </ul> </div> ); }; export default WorkspaceList;
You can extend this by adding functionality to start/stop workspaces, create new projects, or manage plugins—just reference the Swagger docs for the correct endpoints.
Step 5: Fix Cross-Origin Issues (CORS)
If your frontend runs on a different domain than Che’s server, you’ll hit CORS errors. Fix this in one of two ways:
- Development: Add a proxy to your frontend’s
package.jsonto route API calls through your dev server:"proxy": "http://<your-che-server-url>" - Production: Configure Che’s server to allow your frontend’s domain in its CORS settings (check Che’s deployment docs for your environment to update this configuration).
Step 6: Test and Deploy
- Start your frontend dev server:
npm startand test all features (login, workspace operations, etc.) - Once you’re satisfied, build the production bundle:
npm run build - Deploy the bundled files to a web server (like Nginx) or a Kubernetes cluster (if Che is hosted there) — ensure the deployed frontend can reach Che’s API endpoint and handle authentication correctly.
- API Versioning: Che’s APIs may change between versions, so always cross-check the Swagger docs for your specific Che release to avoid deprecated endpoints.
- Real-Time Updates: For live events (like workspace status changes), use Che’s WebSocket API instead of polling REST endpoints—you can connect to
ws://<che-server-url>/api/wsto receive real-time notifications. - Error Handling: Add user-friendly error messages for common issues like expired tokens, permission denials, or server downtime.
- Security: Never hardcode authentication tokens in production. Use secure storage (like HttpOnly cookies) and implement token refresh logic.
内容的提问来源于stack exchange,提问作者Jonathan COLLIN

