API ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ VPN ਕਾਰਵਾਈ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
ਕਨੈਕਸ਼ਨ ਨਿਯੰਤਰਣ, ਪ੍ਰੋਫਾਈਲ ਪ੍ਰਬੰਧਨ, ਉਪਭੋਗਤਾ ਪ੍ਰਸ਼ਾਸਨ ਅਤੇ ਨਿਰੀਖਣ ਵੱਖਰੇ API ਹਨ। ਪਹਿਲਾਂ ਵਸਤੂ, ਕਿਰਿਆ ਅਤੇ ਸਫਲਤਾ ਦੀ ਸ਼ਰਤ ਦਾ ਨਾਮ ਦਿਓ।
ਇੱਕ ਉਤਪਾਦ ਪੰਨਾ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਸ ਕੋਲ API ਹੈ, ਅਤੇ ਏਕੀਕਰਣ ਮੀਟਿੰਗ ਦੂਜੇ ਸਵਾਲ 'ਤੇ ਅਟਕ ਜਾਂਦੀ ਹੈ। ਕਿਹੜੀ ਕਾਰਵਾਈ, ਕਿਸ ਵਸਤੂ 'ਤੇ, ਕਿਸ ਵੱਲੋਂ ਬੁਲਾਈ ਗਈ, ਅਤੇ ਸਫਲਤਾ ਕੀ ਗਿਣੀ ਜਾਂਦੀ ਹੈ? ਉਤਪਾਦਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਚਾਰਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਆਮ ਤੌਰ 'ਤੇ ਅੱਧੇ ਉਮੀਦਵਾਰ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਬਾਕੀ ਤੁਲਨਾ ਨੂੰ ਵੀ ਅਜਿਹੀ ਚੀਜ਼ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਟੈਸਟ ਨਿਪਟਾ ਸਕਦਾ ਹੈ।
«API ਹੈ» ਨੂੰ ਇੱਕ ਕਾਰਵਾਈ ਨਾਲ ਬਦਲੋ
API ਇੱਕ ਢੋਆ-ਢੁਆਈ ਹੈ, ਯੋਗਤਾ ਨਹੀਂ। REST ਅੰਤ-ਬਿੰਦੂ, ਸਥਾਨਕ ਸਾਕਟ ਅਤੇ ਕਮਾਂਡ-ਲਾਈਨ ਲਪੇਟ ਸਭ ਨੂੰ API ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਬਰਾਬਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨਹੀਂ ਦਿੰਦੇ।
ਦਸਤਾਵੇਜ਼ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਵਾਕ ਵਜੋਂ ਲਿਖੋ।
ਸਥਾਨਕ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨਾ ਸਾਹਮਣੇ ਉਪਭੋਗਤਾ ਵਾਲੀ ਕਲਾਇੰਟ-ਪਾਸੇ ਦੀ ਕਿਰਿਆ ਹੈ। ਡਿਵਾਈਸ ਪ੍ਰੋਫਾਈਲ ਜਾਰੀ ਕਰਨਾ ਪਿੱਛੇ ਸੂਚੀ ਵਾਲੀ ਪ੍ਰਬੰਧਨ ਕਿਰਿਆ ਹੈ। ਉਪਭੋਗਤਾ ਦੀ ਪਹੁੰਚ ਬੰਦ ਕਰਨਾ ਲੇਖਾ-ਪਰਖ ਅਤੇ ਰਿਕਾਰਡ ਵਾਲੀ ਪ੍ਰਸ਼ਾਸਕੀ ਕਿਰਿਆ ਹੈ। ਇਹ ਤਿੰਨ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ, ਵੱਖਰੀਆਂ ਟੀਮਾਂ ਦੀ ਮਾਲਕੀ ਹੇਠ, ਵੱਖਰੇ ਅਧਿਕਾਰ ਨਾਲ ਰਹਿੰਦੇ ਹਨ।
ਚਾਰ ਖੇਤਰ ਜੋ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਟੈਸਟਯੋਗ ਬਣਾਉਂਦੇ ਹਨ
ਹਰ ਕਾਰਵਾਈ ਲਈ ਚਾਰ ਖੇਤਰ ਭਰੋ: ਵਸਤੂ, ਕਿਰਿਆ, ਬੁਲਾਉਣ ਵਾਲਾ ਅਤੇ ਸਫਲਤਾ ਦੀ ਸ਼ਰਤ। ਖਾਲੀ ਖੇਤਰ ਵਾਲਾ ਇਕਰਾਰਨਾਮਾ ਸਿਰਫ਼ ਇੱਕ ਇੱਛਾ ਹੈ।
ਸਾਰਣੀ ਹੀ ਪੂਰੀ ਵਰਕਸ਼ੀਟ ਹੈ:
| Field | Question | Example |
|---|---|---|
| Object | What is being acted on? | One enrolled device |
| Action | Observe, create, change, start, stop, or revoke? | Revoke |
| Caller | Which identity calls it? | Deployment service |
| Success | What observable state proves it? | Future sign-in denied |
ਸਫਲਤਾ ਦੀ ਸ਼ਰਤ ਉਹ ਖੇਤਰ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਏਕੀਕਰਣ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸੰਭਾਲੀ ਸੈਟਿੰਗ ਸਰਗਰਮ ਟਨਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਬੰਦ ਕੀਤਾ ਖਾਤਾ ਖਤਮ ਹੋਇਆ ਸੈਸ਼ਨ ਨਹੀਂ ਹੈ।
ਜੇ ਦੋ ਕਾਰਵਾਈਆਂ ਨੂੰ ਵੱਖਰੇ ਬੁਲਾਉਣ ਵਾਲੇ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਉਹ ਦੋ ਏਕੀਕਰਣ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਸੇਵਾ ਖਾਤੇ ਵਿੱਚ ਨੱਥੀ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਦੋਵਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਅਧਿਕਾਰ ਤੋਂ ਵੱਧ ਦੇਣਾ ਹੈ।
ਇੰਟਰਫੇਸ ਨੂੰ ਉਸਦੀ ਅਸਲ ਪਰਤ ਨਾਲ ਮਿਲਾਓ
OpenVPN ਦੇ ਭਾਈਚਾਰੇ ਦਾ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫੇਸ TCP ਜਾਂ Unix ਸਾਕਟ ਰਾਹੀਂ ਡੀਮਨ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਇਸਦੇ ਹੁਕਮਾਂ ਵਿੱਚ ਸਥਿਤੀ ਨਿਰੀਖਣ ਅਤੇ ਡੀਮਨ ਸੰਕੇਤ ਸ਼ਾਮਲ ਹਨ।
ਇਹ ਇਸਨੂੰ ਡੀਮਨ ਨਿਯੰਤਰਣ ਚੈਨਲ ਬਣਾਉਂਦਾ ਹੈ, ਮੇਜ਼ਬਾਨ ਕੀਤਾ ਸਬਸਕ੍ਰਿਪਸ਼ਨ API ਜਾਂ ਉਪਭੋਗਤਾ ਰਜਿਸਟਰੇਸ਼ਨ ਸੇਵਾ ਨਹੀਂ। ਇਸਦਾ ਦਸਤਾਵੇਜ਼ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਨਾ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਪਰਤ 'ਤੇ ਨਿਰਮਾਣ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਵਸਤੂ ਦੀ ਮਾਲਕ ਨਹੀਂ ਹੈ।
ਉਹ ਦਸਤਾਵੇਜ਼ ਇਹ ਵੀ ਕਹਿੰਦਾ ਹੈ ਕਿ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਆਪਣੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਹੈ। ਜੋ ਸਾਕਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਉਹ ਡੀਮਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿਯੰਤਰਣ ਮੰਨੋ, ਮੈਟ੍ਰਿਕ ਫੀਡ ਨਹੀਂ। ਇਸਨੂੰ loopback ਜਾਂ Unix ਸਾਕਟ ਨਾਲ ਬੰਨ੍ਹੋ, ਅਤੇ ਜੇ ਦੂਰ ਦੇ ਬੁਲਾਉਣ ਵਾਲੇ ਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸੀਮਿਤ ਪ੍ਰਬੰਧ ਪਿੱਛੇ ਰੱਖੋ। ਸਹੂਲਤ ਲਈ ਇਸਨੂੰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਖੋਲ੍ਹਣਾ ਨਿਯੰਤਰਣ ਚੈਨਲ ਨੂੰ ਘਟਨਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਕਾਲ ਤੋਂ ਬਾਅਦ ਦਾ ਵਿਵਹਾਰ ਨਿਰਧਾਰਿਤ ਕਰੋ
ਸਵੀਕ੍ਰਿਤੀ ਪੂਰਤੀ ਵਰਗੀ ਨਹੀਂ ਹੈ। ਟਨਲ ਚੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਡੀਮਨ ਵਾਪਸ ਆ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਦਸਤਾਵੇਜ਼ ਵਾਲੀ ਪੂਰਤੀ ਜਾਂ ਅਸਫਲਤਾ ਘਟਨਾ ਦੀ ਉਡੀਕ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੀ ਭੇਜੀ ਬੇਨਤੀ ਨਾਲ ਜੋੜੋ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਵਾਬ ਗੁੰਮ ਹੋਣ 'ਤੇ ਬੁਲਾਉਣ ਵਾਲਾ ਕੀ ਕਰੇ। ਸਿਰਜਣਾ ਜਾਂ ਮੁੜ-ਕਨੈਕਟ ਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਦੁਹਰਾਉਣਾ ਇਹ ਜਾਂਚਣਾ ਨਹੀਂ ਹੈ ਕਿ ਪਹਿਲੀ ਬੇਨਤੀ ਦਾ ਪਹਿਲਾਂ ਹੀ ਅਸਰ ਪੈ ਚੁੱਕਾ ਹੈ।
ਪਹੁੰਚ ਹਟਾਉਣਾ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵੱਖਰੀਆਂ ਕਿਰਿਆਵਾਂ ਹਨ: ਭਵਿੱਖੀ ਸਾਈਨ-ਇਨ ਰੋਕਣਾ, ਸਰਗਰਮ ਸੈਸ਼ਨ ਖਤਮ ਕਰਨਾ ਅਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੱਦ ਕਰਨਾ। ਨੀਤੀ ਜੋ ਸੱਚਮੁੱਚ ਮੰਗਦੀ ਹੈ ਉਹੀ ਮੰਗੋ, ਅਤੇ ਇਕਰਾਰਨਾਮੇ ਵਿੱਚ ਦੱਸੋ ਕਿ ਕਿਹੜਾ ਕਿਹੜਾ ਹੈ। ਬਿਨਾਂ ਸਬੂਤ ਇੱਕ ਸਫਲ ਖਾਤਾ ਅੱਪਡੇਟ ਨੂੰ ਪੂਰਨ ਰੱਦ ਕਰਨਾ ਨਾ ਕਹੋ। ਘਟਨਾ ਵੇਲੇ, ਜਦੋਂ ਘੜੀ ਚੱਲ ਰਹੀ ਹੋਵੇ, ਇਹ ਫ਼ਰਕ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ।
ਪਾਇਲਟ ਨਾਲ ਇਕਰਾਰਨਾਮਾ ਜਾਂਚੋ
ਛੋਟੇ ਮਨਜ਼ੂਰ ਪਾਇਲਟ ਨੂੰ ਸਫਲਤਾ, ਰੱਦ, ਰੁਕਾਵਟ ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਕਵਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਫਿਰ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਵਾਈ ਜੋ ਮਨਜ਼ੂਰ ਜਾਂ ਰੱਦ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਡੀਮਨ-ਪੱਧਰੀ ਇੰਟਰਫੇਸ ਲਈ ਦੋ ਹੁਕਮ ਨਿਰੀਖਣ ਅਤੇ ਸੰਕੇਤ ਦਾ ਅਭਿਆਸ ਕਰਦੇ ਹਨ:
echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505ਸਿਰਫ਼ ਉਹੀ ਅਧਿਕਾਰ ਦਿਓ ਜੋ ਕਾਰਵਾਈ ਮੰਗਦੀ ਹੈ। ਭੇਤ ਰੋਜ਼ਾਨਾ ਲੌਗਾਂ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ ਕਾਫ਼ੀ ਨਿੱਜੀ ਵੇਰਵਾ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਦੱਸ ਸਕੋ ਕਿ ਕਿਹੜਾ ਟਾਰਗਿਟ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ ਅਤੇ ਕਿਵੇਂ ਖਤਮ ਹੋਇਆ।
ਉਸ ਕੇਸ ਲਈ ਰਿਕਵਰੀ ਮਾਰਗ ਲਿਖੋ ਜਦੋਂ ਨਿਯੰਤਰਣ API ਆਪ ਹੀ ਡਾਊਨ ਹੋਵੇ। ਉਹ ਇੰਟਰਫੇਸ ਚੁਣੋ ਜੋ ਵਸਤੂ ਅਤੇ ਉਸਦੇ ਜੀਵਨ-ਚੱਕਰ ਦਾ ਮਾਲਕ ਹੈ; ਉਤਪਾਦ ਪੰਨੇ ਦੇ ਸਵੈਚਾਲਨ ਦਾਅਵੇ ਬਦਲ ਨਹੀਂ ਹਨ।