REST API ਕਿਵੇਂ ਬਣਾਈਏ: ਡਿਜ਼ਾਈਨ, ਸੁਰੱਖਿਆ ਅਤੇ ਡਿਪਲੌਏਮੈਂਟ

REST API ਬਣਾਉਣ ਲਈ, ਆਪਣੀ ਐਪ ਵਿੱਚ ਸੰਭਾਲੇ ਜਾਣ ਵਾਲੇ ਰਿਸੋਰਸ (ਯੂਜ਼ਰ, ਆਰਡਰ, ਬੁਕਿੰਗ) ਲਿਖੋ, ਹਰ ਇੱਕ ਨੂੰ /orders ਅਤੇ /orders/{id} ਵਰਗਾ URL ਦਿਓ, ਅਤੇ ਕਾਰਵਾਈਆਂ ਲਈ HTTP ਮੈਥਡ ਵਰਤੋ: ਪੜ੍ਹਨ ਲਈ GET, ਬਣਾਉਣ ਲਈ POST, ਬਦਲਣ ਲਈ PATCH, ਹਟਾਉਣ ਲਈ DELETE। ਅਰਥਪੂਰਨ ਸਟੇਟਸ ਕੋਡਾਂ ਨਾਲ JSON ਵਾਪਸ ਕਰੋ, ਹਰ ਇਨਪੁੱਟ ਦੀ ਵੈਲੀਡੇਸ਼ਨ ਕਰੋ, ਸਰਵਰ 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਹਰ ਰਿਕਾਰਡ ਲਈ ਇਜਾਜ਼ਤ ਦੀ ਜਾਂਚ ਲਾਜ਼ਮੀ ਕਰੋ, ਅਤੇ ਸੂਚੀਆਂ ਨੂੰ ਪੰਨਿਆਂ ਵਿੱਚ ਵੰਡੋ। ਫਿਰ ਐਂਡਪੁਆਇੰਟਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਅਤੇ API ਨੂੰ HTTPS ਪਿੱਛੇ ਡਿਪਲੌਏ ਕਰੋ।

ਇਹ ਗਾਈਡ ਡਿਜ਼ਾਈਨ ਦੇ ਫ਼ੈਸਲੇ, ਰੂਟਾਂ ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਸੈੱਟ, AI ਐਪ ਬਿਲਡਰ ਲਈ ਪ੍ਰੌਮਪਟ, ਅਤੇ ਉਹ ਗ਼ਲਤੀਆਂ ਕਵਰ ਕਰਦੀ ਹੈ ਜੋ ਸੁਰੱਖਿਆ ਛੇਕ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਜੇ API ਤੁਹਾਡੇ ਲਈ ਨਵਾਂ ਹੈ, ਤਾਂ API ਕੀ ਹੁੰਦਾ ਹੈ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।

REST API ਕਦੋਂ ਚਾਹੀਦਾ ਹੈ

• ਤੁਹਾਡੇ ਵੈੱਬ ਫ਼ਰੰਟਐਂਡ ਨੂੰ ਸਰਵਰ ਤੋਂ ਡੇਟਾ ਸੇਵ ਅਤੇ ਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ
• ਮੋਬਾਈਲ ਐਪ, ਭਾਈਵਾਲ ਜਾਂ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਨੂੰ ਤੁਹਾਡੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ
• ਹੋਰ ਸਰਵਿਸਾਂ ਤੁਹਾਨੂੰ ਇਵੈਂਟ ਭੇਜਦੀਆਂ ਹਨ (webhooks)
• ਤੁਸੀਂ ਫ਼ਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਟੀਮਾਂ ਵਿਚਕਾਰ ਕੰਮ ਵੰਡ ਰਹੇ ਹੋ

REST ਸਭ ਤੋਂ ਆਮ ਸਟਾਈਲ ਹੈ, ਪਰ ਇਕੱਲਾ ਨਹੀਂ। REST ਬਨਾਮ GraphQL ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਲਚਕੀਲਾ ਕਵੈਰੀ ਐਂਡਪੁਆਇੰਟ ਕਦੋਂ ਬਿਹਤਰ ਬੈਠਦਾ ਹੈ।

ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ: ਰਿਸੋਰਸ ਅਤੇ ਰੂਟ

ਆਪਣੀ ਐਪ ਦੇ ਨਾਂਵ ਅਤੇ ਲੋਕ ਉਨ੍ਹਾਂ ਨਾਲ ਕੀ ਕਰਦੇ ਹਨ, ਲਿਖੋ। ਇੱਕ ਸਧਾਰਨ ਬੁਕਿੰਗ ਐਪ ਲਈ:

ਇਹ ਬਣਾਓ, ਪੜ੍ਹੋ, ਬਦਲੋ ਅਤੇ ਹਟਾਓ (CRUD) ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ; ਵੇਖੋ CRUD ਕੀ ਹੈ। ਕੁਝ ਸੰਮੇਲਨ ਜੋ ਵਰਤਣ ਯੋਗ ਹਨ:

• URL ਵਿੱਚ ਬਹੁਵਚਨ ਨਾਂਵ, ਕ੍ਰਿਆ ਨਹੀਂ: /bookings, /getBookings ਨਹੀਂ।
• ਸਿਰਫ਼ ਇੱਕ ਪੱਧਰ ਤੱਕ ਨੈਸਟ ਕਰੋ ਜਦੋਂ ਮਾਲਕੀ ਸਪਸ਼ਟ ਹੋਵੇ: /bookings/{id}/notes।
• CRUD ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਸਬ-ਰਿਸੋਰਸ ਹੋ ਸਕਦੀਆਂ ਹਨ: POST /bookings/{id}/cancel ਕਿਸੇ ਜਾਦੂਈ PATCH ਨਾਲੋਂ ਸਾਫ਼ ਹੈ।
• ਫ਼ੀਲਡਾਂ ਦੇ ਨਾਂ ਇਕਸਾਰ ਰੱਖੋ, ਜਿਵੇਂ ਹਰ ਥਾਂ created_at।

ਸਟੇਟਸ ਕੋਡ ਅਤੇ ਗ਼ਲਤੀਆਂ

ਮਿਆਰੀ HTTP ਕੋਡ ਵਰਤੋ ਤਾਂ ਕਿ ਕਲਾਇੰਟ ਟੈਕਸਟ ਪੜ੍ਹੇ ਬਿਨਾਂ ਸਮਝ ਜਾਵੇ ਕਿ ਕੀ ਹੋਇਆ:

ਗ਼ਲਤੀਆਂ ਇੱਕੋ ਜਿਹੇ JSON ਢਾਂਚੇ ਵਿੱਚ ਵਾਪਸ ਕਰੋ, ਜਿਵੇਂ {"error": {"code": "slot_taken", "message": "That time is no longer available."}}, ਅਤੇ ਜਵਾਬਾਂ ਵਿੱਚ ਕਦੇ ਵੀ ਸਟੈਕ ਟਰੇਸ ਜਾਂ ਡੇਟਾਬੇਸ ਗ਼ਲਤੀਆਂ ਨਾ ਪਾਓ।

ਵਿਕਲਪ ਅਤੇ ਸਮਝੌਤੇ

ਕਦਮ-ਦਰ-ਕਦਮ

1. ਰਿਸੋਰਸ ਅਤੇ ਰੂਟ ਲਿਖੋ ਜਿਵੇਂ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਨਾਲ ਇਹ ਵੀ ਕਿ ਹਰ ਇੱਕ ਨੂੰ ਕੌਣ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
2. ਡੇਟਾ ਮਾਡਲ ਬਣਾਓ ਆਪਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ, ਲੋੜੀਂਦੀਆਂ ਫ਼ੀਲਡਾਂ ਅਤੇ ਸੰਬੰਧਾਂ ਨਾਲ।
3. ਪਹਿਲਾਂ ਪੜ੍ਹਨ ਵਾਲੇ ਰੂਟ ਬਣਾਓ, ਫਿਰ ਬਣਾਉਣ, ਅੱਪਡੇਟ ਅਤੇ ਹਟਾਉਣ ਵਾਲੇ।
4. ਹਰ ਲਿਖਤ 'ਤੇ ਇਨਪੁੱਟ ਵੈਲੀਡੇਟ ਕਰੋ ਇੱਕ ਸਕੀਮਾ ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ: ਲੋੜੀਂਦੀਆਂ ਫ਼ੀਲਡਾਂ, ਕਿਸਮਾਂ, ਲੰਬਾਈ, ਮਨਜ਼ੂਰ ਮੁੱਲ। ਅਣਜਾਣ ਫ਼ੀਲਡਾਂ ਰੱਦ ਕਰੋ।
5. ਪ੍ਰਮਾਣੀਕਰਨ ਜੋੜੋ, ਫਿਰ ਹਰ ਰਿਕਾਰਡ ਲਈ ਅਧਿਕਾਰ: /bookings/42 ਲੋਡ ਕਰਨ ਵੇਲੇ ਜਾਂਚੋ ਕਿ ਬੁਕਿੰਗ 42 ਕਾਲ ਕਰਨ ਵਾਲੇ ਦੀ ਹੈ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਕੋਈ ਲੌਗਇਨ ਹੈ।
6. ਹਰ ਸੂਚੀ ਨੂੰ ਪੇਜੀਨੇਟ ਕਰੋ ਅਤੇ ਪੰਨੇ ਦਾ ਆਕਾਰ ਸੀਮਤ ਕਰੋ।
7. ਲੌਗਇਨ ਅਤੇ ਮਹਿੰਗੇ ਰੂਟਾਂ ਦੀ ਰੇਟ ਸੀਮਾ ਲਗਾਓ। ਰੇਟ ਲਿਮਿਟਿੰਗ ਵੇਖੋ।
8. CORS ਸੈੱਟ ਕਰੋ ਸਿਰਫ਼ ਉਦੋਂ ਜਦੋਂ ਹੋਰ ਡੋਮੇਨਾਂ ਦੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੇ API ਕਾਲ ਕਰਨੀ ਹੋਵੇ, ਅਤੇ ਉਨ੍ਹਾਂ ਔਰਿਜਿਨ ਨੂੰ ਸਾਫ਼-ਸਾਫ਼ ਲਿਖੋ। CORS ਗ਼ਲਤੀਆਂ ਠੀਕ ਕਰਨਾ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਕਿਹੜੀਆਂ ਗ਼ਲਤੀਆਂ ਆਉਣਗੀਆਂ।
9. ਹਰ ਰੂਟ ਲਈ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਟੈਸਟ ਲਿਖੋ, ਫ਼ੇਲ੍ਹ ਹੋਣ ਵਾਲੇ ਮਾਮਲਿਆਂ ਸਮੇਤ।
10. ਡਿਪਲੌਏ ਕਰੋ ਗੁਪਤ ਜਾਣਕਾਰੀ ਵਾਤਾਵਰਨ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ, HTTPS ਨਾਲ, ਲੌਗਾਂ ਅਤੇ ਹੈਲਥ ਚੈੱਕ ਨਾਲ।

ਆਪਣੇ AI ਬਿਲਡਰ ਨੂੰ ਦੇਣ ਯੋਗ ਪ੍ਰੌਮਪਟ

ਸਕੈਫੋਲਡ:

ਬੁਕਿੰਗਾਂ ਲਈ ਇਨ੍ਹਾਂ ਰੂਟਾਂ ਵਾਲਾ REST API ਬਣਾਓ: GET /api/health, GET /api/bookings (ਪੇਜੀਨੇਟਡ, ਪ੍ਰਤੀ ਪੰਨਾ ਵੱਧ ਤੋਂ ਵੱਧ 50), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id। ਡੇਟਾ ਸਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰੋ। ਰਿਕਵੈਸਟ ਬਾਡੀ ਨੂੰ ਸਕੀਮਾ ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ ਵੈਲੀਡੇਟ ਕਰੋ ਅਤੇ ਅਣਜਾਣ ਫ਼ੀਲਡਾਂ ਰੱਦ ਕਰੋ। ਗ਼ਲਤੀਆਂ ਨੂੰ {"error": {"code", "message"}} ਵਜੋਂ JSON ਵਿੱਚ ਵਾਪਸ ਕਰੋ, ਸਹੀ ਸਟੇਟਸ ਕੋਡਾਂ ਨਾਲ (400, 401, 403, 404, 409)। ਗੁਪਤ ਜਾਣਕਾਰੀ ਵਾਤਾਵਰਨ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਰੱਖੋ।

ਸੁਰੱਖਿਆ:

ਹਰ ਬੁਕਿੰਗ ਰੂਟ 'ਤੇ ਲੌਗਇਨ ਲਾਜ਼ਮੀ ਕਰੋ। ਹਰ ਰੀਡ, ਅੱਪਡੇਟ ਅਤੇ ਡਿਲੀਟ 'ਤੇ ਸਰਵਰ 'ਤੇ ਜਾਂਚੋ ਕਿ ਬੁਕਿੰਗ ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਦੀ ਹੈ; ਜੇ ਨਹੀਂ, ਤਾਂ 404 ਵਾਪਸ ਕਰੋ। ਬੇਨਤੀ ਬਾਡੀ ਵਿੱਚੋਂ ਯੂਜ਼ਰ ID ਜਾਂ ਰੋਲ ਕਦੇ ਸਵੀਕਾਰ ਨਾ ਕਰੋ। POST /api/bookings ਨੂੰ ਪ੍ਰਤੀ ਯੂਜ਼ਰ ਪ੍ਰਤੀ ਮਿੰਟ 20 ਤੱਕ ਸੀਮਤ ਕਰੋ। ਸਰਵਰ 'ਤੇ ਗ਼ਲਤੀਆਂ ਲੌਗ ਕਰੋ, ਪਰ ਸਟੈਕ ਟਰੇਸ ਵਾਪਸ ਨਾ ਕਰੋ।

ਦਸਤਾਵੇਜ਼:

ਇਨ੍ਹਾਂ ਰੂਟਾਂ ਦਾ OpenAPI ਵੇਰਵਾ ਲਿਖੋ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਉਦਾਹਰਨ ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬਾਂ ਵਾਲਾ ਛੋਟਾ README ਲਿਖੋ।

ਆਪਣੇ API ਦੀ ਜਾਂਚ

ਫ਼ਰੰਟਐਂਡ ਤੋਂ ਬਾਹਰੋਂ ਟੈਸਟ ਕਰੋ, ਕਿਉਂਕਿ ਹਮਲਾਵਰ ਵੀ ਇੰਝ ਹੀ ਕਰਨਗੇ:

• ਹਰ ਰੂਟ ਸਹੀ ਇਨਪੁੱਟ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਢਾਂਚਾ ਤੇ ਕੋਡ ਵਾਪਸ ਕਰਦਾ ਹੈ
• ਗੁੰਮ ਜਾਂ ਗ਼ਲਤ ਫ਼ੀਲਡਾਂ 'ਤੇ ਸਾਫ਼ ਸੁਨੇਹੇ ਨਾਲ 400 ਮਿਲਦਾ ਹੈ
• ਹਰ ਸੁਰੱਖਿਅਤ ਰੂਟ 'ਤੇ ਟੋਕਨ ਨਾ ਹੋਣ 'ਤੇ 401 ਮਿਲਦਾ ਹੈ
• ਯੂਜ਼ਰ A ਵੱਲੋਂ ਯੂਜ਼ਰ B ਦਾ ID ਨਾਲ ਰਿਕਾਰਡ ਮੰਗਣ 'ਤੇ 404 ਜਾਂ 403 ਮਿਲਦਾ ਹੈ
• ਸੂਚੀਆਂ ਪੇਜੀਨੇਟਡ ਹਨ, ਅਤੇ ਬਹੁਤ ਵੱਡੀ limit ਸੀਮਤ ਹੋ ਜਾਂਦੀ ਹੈ
• ਡੁਪਲੀਕੇਟ ਜਾਂ ਟਕਰਾਅ ਵਾਲੀਆਂ ਬਣਾਉਣ ਦੀਆਂ ਬੇਨਤੀਆਂ 409 ਦਿੰਦੀਆਂ ਹਨ, 500 ਨਹੀਂ
• ਰੇਟ ਲਿਮਿਟ 'ਤੇ 429 ਮਿਲਦਾ ਹੈ
• ਗ਼ਲਤੀ ਜਵਾਬਾਂ ਵਿੱਚ ਸਟੈਕ ਟਰੇਸ, SQL ਜਾਂ ਗੁਪਤ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੁੰਦੀ
• CORS ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਔਰਿਜਿਨ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ

ਆਮ ਗ਼ਲਤੀਆਂ

• ਲੌਗਇਨ ਚੈੱਕ ਕਰਨਾ, ਪਰ ਮਾਲਕੀ ਨਹੀਂ। ਸਭ ਤੋਂ ਆਮ API ਛੇਕ: ਕੋਈ ਵੀ ਲੌਗਇਨ ਯੂਜ਼ਰ ID ਬਦਲ ਕੇ ਕਿਸੇ ਵੀ ਰਿਕਾਰਡ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।
• ਕਲਾਇੰਟ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ। ਬੇਨਤੀ ਬਾਡੀ ਦੀਆਂ ਕੀਮਤਾਂ, ਰੋਲ ਅਤੇ ਯੂਜ਼ਰ ID ਬਦਲੇ ਜਾ ਸਕਦੇ ਹਨ।
• ਪੂਰੀਆਂ ਡੇਟਾਬੇਸ ਕਤਾਰਾਂ ਵਾਪਸ ਕਰਨਾ। ਪਾਸਵਰਡ ਹੈਸ਼ ਅਤੇ ਅੰਦਰੂਨੀ ਫ਼ੀਲਡਾਂ ਲੀਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਹਰ ਜਵਾਬ ਵਿੱਚ ਕੀ ਜਾਵੇ, ਇਹ ਤੈਅ ਕਰੋ।
• ਬੇਹੱਦ ਸੂਚੀਆਂ। ਹਰ ਰਿਕਾਰਡ ਲਈ ਇੱਕ ਬੇਨਤੀ ਪੂਰੀ ਐਪ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦੀ ਹੈ।
• ਗ਼ਲਤੀ ਅੰਦਰ ਰੱਖ ਕੇ 200 OK। ਕਲਾਇੰਟ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਹ ਫ਼ੇਲ੍ਹ ਹੋਇਆ।
• CORS ਸਭ ਕੁਝ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਸੈੱਟ ਉਸ API 'ਤੇ ਜੋ ਕੁਕੀਜ਼ ਵਰਤਦਾ ਹੈ।
• ਕੋਈ ਹੈਲਥ ਚੈੱਕ ਜਾਂ ਲੌਗ ਨਹੀਂ, ਇਸ ਲਈ ਆਊਟੇਜ ਦਾ ਪਤਾ ਯੂਜ਼ਰਾਂ ਤੋਂ ਲੱਗਦਾ ਹੈ।

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਵਿਆਪਕ ਜਾਂਚ ਲਈ, AI ਨਾਲ ਬਣੀਆਂ ਐਪਾਂ ਲਈ ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ ਵੇਖੋ।

Mythex ਵਿੱਚ REST API ਬਣਾਉਣਾ

ਤੁਸੀਂ Mythex ਤੋਂ ਆਪਣੀ ਐਪ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਜਾਂ ਵੱਖਰੀ ਸਰਵਿਸ ਵਜੋਂ API ਮੰਗ ਸਕਦੇ ਹੋ। ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਰੈਸਿਪੀ REST API ਬੈਕਐਂਡ ਵਿੱਚ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੌਮਪਟ ਹੈ: ਆਪਣਾ ਫ਼ਰੇਮਵਰਕ ਅਤੇ ਰੂਟ ਦੱਸੋ, ਸਾਫ਼ JSON ਗ਼ਲਤੀਆਂ ਮੰਗੋ, ਗੁਪਤ ਜਾਣਕਾਰੀ ਵਾਤਾਵਰਨ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ Dockerfile ਸ਼ਾਮਲ ਕਰੋ। Node, Python, C#, Java ਅਤੇ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਕੰਟੇਨਰ ਬੈਕਐਂਡ Dockerfile ਰਾਹੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ Mythex Publish ਤੋਂ ਡਿਪਲੌਏ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ (API ਬੈਕਐਂਡ)। ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵੈੱਬਸਾਈਟ ਅਤੇ API ਸਰਵਰ ਨਾਲ-ਨਾਲ ਚੱਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦੇ ਹੋ। ਕੀਆਂ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਸੀਕ੍ਰੇਟ ਵਜੋਂ ਰੱਖੋ, ਅਤੇ ਜੇ API ਨੂੰ ਡੇਟਾਬੇਸ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਚੈਟ ਵਿੱਚ ਮੰਗੋ। API ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸ਼ਡਿਊਲ ਕੀਤੇ ਕੰਮਾਂ ਲਈ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਕਿਵੇਂ ਚਲਾਈਏ ਵੇਖੋ।

ਸਵਾਲ