ਤਾਂ ਕੀ ਇਹ RAML ਜਾਂ OAS (Swagger) ਹੈ?

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਗਤੀਸ਼ੀਲ ਸੰਸਾਰ ਵਿੱਚ, ਕੁਝ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ - ਕਿਸੇ ਵੀ ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਵੱਖ-ਵੱਖ ਫਰੇਮਵਰਕ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਇਕਰਾਰਨਾਮੇ ਹੀ ਬਦਲੇ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਕਿ ਅੰਦਰੂਨੀ ਰੂਪਾਂਤਰਾਂ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਕੁਝ ਸਥਾਈ ਆਧਾਰ 'ਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨਾਲ ਬਾਹਰੋਂ ਇੰਟਰੈਕਟ ਕੀਤਾ ਜਾ ਸਕੇ। ਅਤੇ ਅੱਜ ਅਸੀਂ ਇਕਰਾਰਨਾਮੇ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਇੱਕ ਫਾਰਮੈਟ ਚੁਣਨ ਦੀ ਸਾਡੀ ਸਮੱਸਿਆ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਅਤੇ ਸਾਡੇ ਦੁਆਰਾ ਲੱਭੀਆਂ ਗਈਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ ਨੂੰ ਸਾਂਝਾ ਕਰਾਂਗੇ।

ਪੋਸਟ ਤਿਆਰ ਅੰਨਾ ਮੇਲੇਖੋਵਾ и ਵਲਾਦੀਮੀਰ ਲੈਪਟਿਨ

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼। ਐਕ੍ਰੋਨਿਸ ਸਾਈਬਰ ਕਲਾਊਡ ਨੂੰ ਵਿਕਸਿਤ ਕਰਦੇ ਸਮੇਂ, ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਅਸੀਂ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚ ਨਹੀਂ ਸਕਦੇ। ਅਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਰਸਮੀ ਕੀਤੇ ਬਿਨਾਂ ਅਸੰਭਵ ਹੈ, ਜੋ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੇ ਇੰਟਰਫੇਸ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਪਰ ਜਦੋਂ ਇੱਕ ਉਤਪਾਦ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਭਾਗ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਕਰਾਰਨਾਮੇ ਦਾ ਵਿਕਾਸ ਇੱਕ ਨਿਯਮਤ ਗਤੀਵਿਧੀ ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਦੇ ਪਰ ਪ੍ਰਕਿਰਿਆ ਅਨੁਕੂਲਨ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਇੰਟਰਫੇਸ (ਇਕਰਾਰਨਾਮਾ) ਅਤੇ ਲਾਗੂਕਰਨ (ਮਾਈਕ੍ਰੋਸਰਵਿਸ) ਇੱਕ ਦੂਜੇ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿ ਵੱਖੋ-ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕੋ ਜਿਹੇ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਇਹ ਕਿ ਇਹਨਾਂ ਸਾਰੇ ਫੈਸਲਿਆਂ ਦੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਫੈਸਲੇ ਲੈਣ ਤੋਂ ਬਿਨਾਂ, ਹਰੇਕ ਟੀਮ ਨੂੰ ਮਜਬੂਰ ਕੀਤਾ ਜਾਵੇਗਾ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਾਰ-ਵਾਰ ਸਮਾਂ ਬਿਤਾਓ.

ਐਮਾਜ਼ਾਨ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਡਾਇਗ੍ਰਾਮ ਤੋਂ ਟਵੀਟ ਵਰਨਰ ਵੋਗਲਿਸ, ਸੀਟੀਓ ਐਮਾਜ਼ਾਨ
ਦੁਬਿਧਾ ਕੀ ਹੈ? ਅਸਲ ਵਿੱਚ, ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਨੂੰ ਇੰਟਰੈਕਟ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ ਹਨ - ਗੂਗਲ ਤੋਂ HTTP ਆਰਾਮ ਅਤੇ gRPC. ਗੂਗਲ ਦੇ ਟੈਕਨਾਲੋਜੀ ਸਟੈਕ ਵਿੱਚ ਫਸਣ ਦੀ ਇੱਛਾ ਨਾ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ HTTP ਆਰਾਮ ਦੀ ਚੋਣ ਕੀਤੀ। HTTP REST ਕੰਟਰੈਕਟ ਐਨੋਟੇਸ਼ਨਾਂ ਨੂੰ ਅਕਸਰ ਦੋ ਫਾਰਮੈਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: RAML ਅਤੇ OAS, ਜੋ ਪਹਿਲਾਂ ਸਵੈਗਰ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਸੀ। ਇਸਲਈ, ਹਰੇਕ ਵਿਕਾਸ ਟੀਮ ਨੂੰ ਮਿਆਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣਨ ਦੀ ਜ਼ਰੂਰਤ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਪਰ ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਇਹ ਚੋਣ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ।

ਐਨੋਟੇਸ਼ਨਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਐਨੋਟੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਕਿ ਇੱਕ ਬਾਹਰੀ ਉਪਭੋਗਤਾ ਆਸਾਨੀ ਨਾਲ ਇਹ ਪਤਾ ਲਗਾ ਸਕੇ ਕਿ ਇਸਦੇ HTTP ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਤੁਹਾਡੀ ਸੇਵਾ ਨਾਲ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਭਾਵ, ਇੱਕ ਬੁਨਿਆਦੀ ਪੱਧਰ 'ਤੇ, ਐਨੋਟੇਸ਼ਨ ਵਿੱਚ ਉਪਲਬਧ ਸਰੋਤਾਂ ਦੀ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸੂਚੀ, ਉਹਨਾਂ ਦੇ HTTP ਵਿਧੀਆਂ, ਬੇਨਤੀ ਬਾਡੀਜ਼, ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਇੱਕ ਸੂਚੀ, ਲੋੜੀਂਦੇ ਅਤੇ ਸਮਰਥਿਤ ਸਿਰਲੇਖਾਂ ਦਾ ਸੰਕੇਤ, ਨਾਲ ਹੀ ਵਾਪਸੀ ਕੋਡ ਅਤੇ ਜਵਾਬ ਫਾਰਮੈਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਕਰਾਰਨਾਮੇ ਦੇ ਐਨੋਟੇਸ਼ਨ ਦਾ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਤੱਤ ਉਹਨਾਂ ਦਾ ਮੌਖਿਕ ਵਰਣਨ ਹੈ ("ਜੇ ਤੁਸੀਂ ਬੇਨਤੀ ਵਿੱਚ ਇਸ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰ ਨੂੰ ਜੋੜਦੇ ਹੋ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?", "ਕੋਡ 400 ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਕੀਤਾ ਜਾਵੇਗਾ?")

ਹਾਲਾਂਕਿ, ਜਦੋਂ ਇਹ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਲਿਖਤੀ ਐਨੋਟੇਸ਼ਨਾਂ ਤੋਂ ਵਾਧੂ ਮੁੱਲ ਕੱਢਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, RAML/Swagger ਦੇ ਆਧਾਰ 'ਤੇ, ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਕੋਡ ਦੋਵੇਂ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਲਈ ਆਪਣੇ ਆਪ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਡਿਵੈਲਪਰ-ਪੋਰਟਲ 'ਤੇ ਅੱਪਲੋਡ ਕਰ ਸਕਦੇ ਹੋ :)।

ਇੱਕ ਢਾਂਚਾਗਤ ਇਕਰਾਰਨਾਮੇ ਦੇ ਵਰਣਨ ਦੀ ਉਦਾਹਰਨ

ਇਕਰਾਰਨਾਮੇ ਦੇ ਵੇਰਵਿਆਂ 'ਤੇ ਅਧਾਰਤ ਮਾਈਕ੍ਰੋਸਰਵਿਸਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਅਭਿਆਸ ਘੱਟ ਆਮ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਐਨੋਟੇਸ਼ਨ ਅਤੇ ਇੱਕ ਕੰਪੋਨੈਂਟ ਦੋਵੇਂ ਲਿਖੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਆਟੋਟੈਸਟ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਇਨਪੁਟ ਡੇਟਾ ਦੇ ਨਾਲ ਸੇਵਾ ਦੀ ਯੋਗਤਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਕੀ ਸੇਵਾ ਇੱਕ ਜਵਾਬ ਕੋਡ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜਿਸਦਾ ਵਰਣਨ ਐਨੋਟੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ? ਕੀ ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਗਲਤ ਡੇਟਾ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ?

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਨਾ ਸਿਰਫ਼ ਇਕਰਾਰਨਾਮੇ ਦੇ ਉੱਚ-ਗੁਣਵੱਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨਾ, ਸਗੋਂ ਐਨੋਟੇਸ਼ਨਾਂ ਦੀ ਕਲਪਨਾ ਕਰਨ ਲਈ ਸਾਧਨ ਵੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਸਰਲ ਬਣਾਉਣਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ. ਭਾਵ, ਜੇ ਆਰਕੀਟੈਕਟ ਨੇ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਤਰੀਕੇ ਨਾਲ ਦਰਸਾਇਆ, ਤਾਂ ਇਸਦੇ ਅਧਾਰ ਤੇ, ਡਿਜ਼ਾਈਨਰ ਅਤੇ ਡਿਵੈਲਪਰ ਵਾਧੂ ਸਮੇਂ ਦੀ ਲਾਗਤ ਤੋਂ ਬਿਨਾਂ ਹੋਰ ਉਤਪਾਦਾਂ ਵਿੱਚ ਸੇਵਾ ਨੂੰ ਲਾਗੂ ਕਰਨਗੇ.

ਅਤਿਰਿਕਤ ਟੂਲਸ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ, RAML ਅਤੇ OAS ਦੋਵਾਂ ਕੋਲ ਮੈਟਾਡੇਟਾ ਜੋੜਨ ਦੀ ਯੋਗਤਾ ਹੈ ਜੋ ਸਟੈਂਡਰਡ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਇਸ ਨੂੰ OAS ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ).

ਆਮ ਤੌਰ 'ਤੇ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਲਈ ਕੰਟਰੈਕਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਰਚਨਾਤਮਕਤਾ ਦੀ ਗੁੰਜਾਇਸ਼ ਬਹੁਤ ਵੱਡੀ ਹੈ... ਘੱਟੋ-ਘੱਟ ਸਿਧਾਂਤ ਵਿੱਚ।

ਸੱਪ ਨਾਲ ਹੇਜਹੌਗ ਦੀ ਤੁਲਨਾ

ਵਰਤਮਾਨ ਵਿੱਚ, ਐਕ੍ਰੋਨਿਸ ਵਿਖੇ ਤਰਜੀਹੀ ਵਿਕਾਸ ਖੇਤਰ ਐਕ੍ਰੋਨਿਸ ਸਾਈਬਰ ਪਲੇਟਫਾਰਮ ਦਾ ਵਿਕਾਸ ਹੈ। ਐਕ੍ਰੋਨਿਸ ਸਾਈਬਰ ਪਲੇਟਫਾਰਮ ਐਕ੍ਰੋਨਿਸ ਸਾਈਬਰ ਕਲਾਉਡ ਅਤੇ ਏਜੰਟ ਹਿੱਸੇ ਦੇ ਨਾਲ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਏਕੀਕਰਨ ਦੇ ਨਵੇਂ ਬਿੰਦੂ ਹਨ। ਹਾਲਾਂਕਿ ਅਸੀਂ RAML ਵਿੱਚ ਵਰਣਿਤ ਸਾਡੇ ਅੰਦਰੂਨੀ APIs ਤੋਂ ਖੁਸ਼ ਸੀ, API ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨੇ ਦੁਬਾਰਾ ਚੋਣ ਦਾ ਸਵਾਲ ਉਠਾਇਆ: ਸਾਡੇ ਕੰਮ ਲਈ ਕਿਹੜਾ ਐਨੋਟੇਸ਼ਨ ਸਟੈਂਡਰਡ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ?

ਸ਼ੁਰੂ ਵਿੱਚ, ਇਹ ਜਾਪਦਾ ਸੀ ਕਿ ਦੋ ਹੱਲ ਸਨ - ਸਭ ਤੋਂ ਆਮ ਵਿਕਾਸ RAML ਅਤੇ Swagger (ਜਾਂ OAS) ਸਨ। ਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਸਾਹਮਣੇ ਆਇਆ ਕਿ ਇੱਥੇ ਘੱਟੋ ਘੱਟ 2 ਵਿਕਲਪ ਨਹੀਂ ਹਨ, ਪਰ 3 ਜਾਂ ਵੱਧ ਹਨ.

ਇੱਕ ਪਾਸੇ RAML ਹੈ - ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਅਤੇ ਕੁਸ਼ਲ ਭਾਸ਼ਾ. ਇਹ ਲੜੀ ਅਤੇ ਵਿਰਾਸਤ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਇਹ ਫਾਰਮੈਟ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਵਰਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਭਾਵ, ਇੱਕ ਉਤਪਾਦ ਨਹੀਂ, ਪਰ ਬਹੁਤ ਸਾਰੀਆਂ ਮਾਈਕਰੋਸਰਵਿਸਜ਼ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇਕਰਾਰਨਾਮੇ ਦੇ ਸਾਂਝੇ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ - ਪ੍ਰਮਾਣੀਕਰਨ ਸਕੀਮਾਂ, ਇੱਕੋ ਜਿਹੇ ਡੇਟਾ ਕਿਸਮਾਂ, ਗਲਤੀ ਸੰਸਥਾਵਾਂ .

ਪਰ RAML ਦੇ ਡਿਵੈਲਪਰ, Mulesoft, Open API ਕੰਸੋਰਟੀਅਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ ਸਵੈਗਰ. ਇਸ ਲਈ, RAML ਨੇ ਇਸਦੇ ਵਿਕਾਸ ਨੂੰ ਮੁਅੱਤਲ ਕਰ ਦਿੱਤਾ. ਇਵੈਂਟ ਦੇ ਫਾਰਮੈਟ ਦੀ ਕਲਪਨਾ ਕਰਨ ਲਈ, ਕਲਪਨਾ ਕਰੋ ਕਿ ਮੁੱਖ ਲੀਨਕਸ ਕੰਪੋਨੈਂਟਸ ਦੇ ਰੱਖ-ਰਖਾਅ ਕਰਨ ਵਾਲੇ ਮਾਈਕਰੋਸਾਫਟ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਛੱਡ ਗਏ ਹਨ। ਇਹ ਸਥਿਤੀ ਸਵੈਗਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਸ਼ਰਤਾਂ ਬਣਾਉਂਦੀ ਹੈ, ਜੋ ਕਿ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਹੋ ਰਹੀ ਹੈ ਅਤੇ ਨਵੀਨਤਮ - ਤੀਜੇ ਸੰਸਕਰਣ ਵਿੱਚ - ਲਚਕਤਾ ਅਤੇ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ RAML ਨਾਲ ਵਿਵਹਾਰਕ ਤੌਰ 'ਤੇ ਮਿਲਦੀ ਹੈ।

ਜੇ ਇੱਕ ਚੀਜ਼ ਲਈ ਨਹੀਂ ...

ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਸਾਰੀਆਂ ਓਪਨ-ਸੋਰਸ ਉਪਯੋਗਤਾਵਾਂ ਨੂੰ OAS 3.0 ਵਿੱਚ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਗੋ ਵਿੱਚ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਲਈ, ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਚੀਜ਼ ਅਨੁਕੂਲਤਾ ਦੀ ਘਾਟ ਹੋਵੇਗੀ ਜਾਓ-ਸਵਾਗਰ ਸਟੈਂਡਰਡ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਲਈ। ਹਾਲਾਂਕਿ, ਸਵੈਗਰ 2 ਅਤੇ ਸਵੈਗਰ 3 ਵਿੱਚ ਅੰਤਰ ਹੈ ਵਿਸ਼ਾਲ. ਉਦਾਹਰਨ ਲਈ, ਤੀਜੇ ਸੰਸਕਰਣ ਵਿੱਚ ਡਿਵੈਲਪਰ:

• ਪ੍ਰਮਾਣਿਕਤਾ ਸਕੀਮਾਂ ਦਾ ਸੁਧਾਰਿਆ ਵੇਰਵਾ
• ਮੁਕੰਮਲ JSON ਸਕੀਮਾ ਸਮਰਥਨ
• ਉਦਾਹਰਨਾਂ ਜੋੜਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਅਪਗ੍ਰੇਡ ਕੀਤਾ ਹੈ

ਸਥਿਤੀ ਮਜ਼ਾਕੀਆ ਹੈ: ਇੱਕ ਸਟੈਂਡਰਡ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ RAML, Swagger 2 ਅਤੇ Swagger 3 ਨੂੰ ਵੱਖਰੇ ਵਿਕਲਪਾਂ ਵਜੋਂ ਵਿਚਾਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਸਿਰਫ ਸਵੈਗਰ 2 ਕੋਲ ਓਪਨਸੋਰਸ ਟੂਲਸ ਲਈ ਚੰਗਾ ਸਮਰਥਨ ਹੈ। RAML ਬਹੁਤ ਲਚਕੀਲਾ...ਅਤੇ ਗੁੰਝਲਦਾਰ ਹੈ, ਅਤੇ Swagger 3 ਨੂੰ ਕਮਿਊਨਿਟੀ ਦੁਆਰਾ ਮਾੜਾ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਮਲਕੀਅਤ ਵਾਲੇ ਟੂਲਸ ਜਾਂ ਵਪਾਰਕ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ, ਜੋ ਕਿ ਕਾਫ਼ੀ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਸਵੈਗਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਚੰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਰੈਡੀਮੇਡ ਪੋਰਟਲ editor.swagger.io, ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਇੱਕ ਐਨੋਟੇਸ਼ਨ ਅਪਲੋਡ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ, ਲਿੰਕਾਂ ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਦੇ ਨਾਲ ਇਸਦਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਵਧੇਰੇ ਬੁਨਿਆਦੀ ਅਤੇ ਘੱਟ ਦੋਸਤਾਨਾ RAML ਲਈ ਅਜਿਹਾ ਕੋਈ ਮੌਕਾ ਨਹੀਂ ਹੈ। ਹਾਂ, ਤੁਸੀਂ GitHub 'ਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ, ਉੱਥੇ ਇੱਕ ਐਨਾਲਾਗ ਲੱਭ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਲਗਾ ਸਕਦੇ ਹੋ। ਹਾਲਾਂਕਿ, ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਕਿਸੇ ਨੂੰ ਪੋਰਟਲ ਦੀ ਸਾਂਭ-ਸੰਭਾਲ ਕਰਨੀ ਪਵੇਗੀ, ਜੋ ਬੁਨਿਆਦੀ ਵਰਤੋਂ ਜਾਂ ਟੈਸਟਿੰਗ ਲੋੜਾਂ ਲਈ ਇੰਨਾ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਵੈਗਰ ਵਧੇਰੇ "ਅਸਿਧਾਂਤ ਰਹਿਤ", ਜਾਂ ਵਧੇਰੇ ਉਦਾਰ ਹੈ - ਇਹ ਕੋਡ ਵਿੱਚ ਟਿੱਪਣੀਆਂ ਤੋਂ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਕਿ, ਬੇਸ਼ਕ, API ਪਹਿਲੇ ਸਿਧਾਂਤ ਦੇ ਵਿਰੁੱਧ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ RAML ਉਪਯੋਗਤਾਵਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ।

ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਵਧੇਰੇ ਲਚਕਦਾਰ ਭਾਸ਼ਾ ਵਜੋਂ RAML ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਸਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਆਪਣੇ ਆਪ ਕਰਨੀਆਂ ਪਈਆਂ। ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ramlfications ਯੂਨਿਟ ਟੈਸਟਾਂ ਵਿੱਚ, ਜੋ ਸਿਰਫ਼ RAML 0.8 ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਸਾਨੂੰ ਬੈਸਾਖੀਆਂ ਜੋੜਨੀਆਂ ਪਈਆਂ ਤਾਂ ਜੋ ਉਪਯੋਗਤਾ RAML ਸੰਸਕਰਣ 1.0 ਨੂੰ "ਖਾ ਸਕੇ"।

ਕੀ ਤੁਹਾਨੂੰ ਚੁਣਨ ਦੀ ਲੋੜ ਹੈ?

RAML ਲਈ ਹੱਲਾਂ ਦੇ ਈਕੋਸਿਸਟਮ ਨੂੰ ਪੂਰਾ ਕਰਨ 'ਤੇ ਕੰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚੇ ਕਿ ਸਾਨੂੰ RAML ਨੂੰ Swagger 2 ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਅਤੇ ਇਸ ਵਿੱਚ ਸਾਰੇ ਆਟੋਮੇਸ਼ਨ, ਤਸਦੀਕ, ਟੈਸਟਿੰਗ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਹ RAML ਦੀ ਲਚਕਤਾ ਅਤੇ Swagger ਤੋਂ ਕਮਿਊਨਿਟੀ ਟੂਲਿੰਗ ਸਹਾਇਤਾ ਦੋਵਾਂ ਦਾ ਲਾਭ ਉਠਾਉਣ ਦਾ ਵਧੀਆ ਤਰੀਕਾ ਹੈ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਦੋ ਓਪਨਸੋਰਸ ਟੂਲ ਹਨ ਜੋ ਕੰਟਰੈਕਟ ਰੂਪਾਂਤਰ ਪ੍ਰਦਾਨ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ:

1. oas-raml-ਕਨਵਰਟਰ ਇੱਕ ਮੌਜੂਦਾ ਅਸਮਰਥਿਤ ਸਹੂਲਤ ਹੈ। ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਖੋਜਿਆ ਕਿ ਇਸ ਵਿੱਚ ਗੁੰਝਲਦਾਰ RAMLs ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ "ਫੈਲੀਆਂ" ਹਨ। ਇਹ ਪ੍ਰੋਗਰਾਮ JavaScript ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਇੱਕ ਸਿੰਟੈਕਸ ਟ੍ਰੀ ਦਾ ਇੱਕ ਆਵਰਤੀ ਟ੍ਰਾਵਰਸਲ ਕਰਦਾ ਹੈ। ਡਾਇਨਾਮਿਕ ਟਾਈਪਿੰਗ ਦੇ ਕਾਰਨ, ਇਸ ਕੋਡ ਨੂੰ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਇੱਕ ਮਰਨ ਵਾਲੀ ਸਹੂਲਤ ਲਈ ਪੈਚ ਲਿਖਣ ਵਿੱਚ ਸਮਾਂ ਬਰਬਾਦ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।
2. webapi-ਪਾਰਸਰ - ਉਸੇ ਕੰਪਨੀ ਦਾ ਇੱਕ ਸਾਧਨ ਜੋ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਅਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ, ਅਤੇ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ ਬਦਲਣ ਲਈ ਤਿਆਰ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਅੱਜ ਤੱਕ, RAML 0.8, RAML 1.0 ਅਤੇ Swagger 2.0 ਲਈ ਸਮਰਥਨ ਦਾ ਐਲਾਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਹਾਲਾਂਕਿ, ਸਾਡੀ ਖੋਜ ਦੇ ਸਮੇਂ, ਉਪਯੋਗਤਾ ਅਜੇ ਵੀ ਸੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗਿੱਲੀ ਅਤੇ ਬੇਕਾਰ. ਡਿਵੈਲਪਰ ਇੱਕ ਕਿਸਮ ਦੀ ਬਣਾਉਂਦੇ ਹਨ IR, ਉਹਨਾਂ ਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਨਵੇਂ ਮਾਪਦੰਡ ਜੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਪਰ ਹੁਣ ਤੱਕ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ.

ਅਤੇ ਇਹ ਉਹ ਸਾਰੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਅਸੀਂ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ। ਸਾਡੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਇੱਕ ਕਦਮ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨਾ ਹੈ ਕਿ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ RAML ਨਿਰਧਾਰਨ ਦੇ ਅਨੁਸਾਰ ਸਹੀ ਹੈ। ਅਸੀਂ ਕਈ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ ਕਿ, ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਨੇ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਸਾਡੀਆਂ ਵਿਆਖਿਆਵਾਂ 'ਤੇ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖ-ਵੱਖ ਮਾੜੇ ਸ਼ਬਦਾਂ ਨਾਲ ਸਹੁੰ ਖਾਧੀ। ਅਤੇ ਹਮੇਸ਼ਾ ਬਿੰਦੂ ਤੱਕ ਨਹੀਂ :).

ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਹੁਣੇ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ, ਜਿਸ ਵਿੱਚ ਕਈ ਸਮੱਸਿਆਵਾਂ ਵੀ ਹਨ (ਕਈ ​​ਵਾਰ ਇਹ ਨੀਲੇ ਰੰਗ ਤੋਂ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਨਿਯਮਤ ਸਮੀਕਰਨਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ)। ਇਸ ਤਰ੍ਹਾਂ, ਸਾਨੂੰ ਮੁਫਤ ਸਾਧਨਾਂ ਦੇ ਅਧਾਰ ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਪਰਿਵਰਤਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਮਿਲਿਆ, ਅਤੇ ਇੱਕ ਵਪਾਰਕ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਭਵਿੱਖ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਓਪਨਸੋਰਸ ਟੂਲ ਹੋਰ ਪਰਿਪੱਕ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਦੌਰਾਨ, "ਮੁਕੰਮਲ" ਲਈ ਲੇਬਰ ਅਤੇ ਸਮੇਂ ਦੀ ਲਾਗਤ ਸਾਨੂੰ ਵਪਾਰਕ ਸੇਵਾ ਦੀ ਲਾਗਤ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਜਾਪਦੀ ਸੀ।

ਸਿੱਟਾ

ਇਸ ਸਭ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ ਅਤੇ ਨੋਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਇਕਰਾਰਨਾਮਿਆਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਇੱਕ ਸਾਧਨ ਦੀ ਚੋਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਤੋਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਕਿਹੜੇ ਬਜਟ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ। ਜੇਕਰ ਅਸੀਂ ਓਪਨਸੋਰਸ ਬਾਰੇ ਭੁੱਲ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਉਤਪਾਦ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਜਾਂਚ ਕਰਨ, ਬਦਲਣ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ। ਪਰ ਉਹ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰ ਬਹੁਤ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ. ਇੱਕ ਵੱਡੀ ਕੰਪਨੀ ਲਈ, ਅਜਿਹੇ ਖਰਚੇ ਸਹਿਣਯੋਗ ਹਨ, ਪਰ ਇੱਕ ਸ਼ੁਰੂਆਤ ਲਈ ਇਹ ਇੱਕ ਵੱਡਾ ਬੋਝ ਬਣ ਸਕਦੇ ਹਨ।

ਟੂਲਸ ਦਾ ਸੈੱਟ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਰਤੋਗੇ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਇਕਰਾਰਨਾਮਾ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਵੈਗਰ 2 ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇਗਾ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਸੁੰਦਰ API ਹੈ, ਕਿਉਂਕਿ RAML ਵਿੱਚ ਤੁਹਾਨੂੰ ਸੇਵਾ ਨੂੰ ਖੁਦ ਬਣਾਉਣਾ ਅਤੇ ਕਾਇਮ ਰੱਖਣਾ ਹੋਵੇਗਾ।
ਤੁਹਾਡੇ ਕੋਲ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਕੰਮ ਹੋਣਗੇ, ਔਜ਼ਾਰਾਂ ਦੀ ਲੋੜ ਓਨੀ ਹੀ ਜ਼ਿਆਦਾ ਹੋਵੇਗੀ, ਅਤੇ ਉਹ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਵੱਖਰੇ ਹਨ, ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ ਤੁਹਾਡੀਆਂ ਲਾਗਤਾਂ ਨੂੰ ਘੱਟ ਕਰਨ ਵਾਲੀ ਚੋਣ ਕਰਨ ਲਈ ਉਪਲਬਧ ਸੰਸਕਰਣਾਂ ਨਾਲ ਤੁਰੰਤ ਆਪਣੇ ਆਪ ਨੂੰ ਜਾਣੂ ਕਰਵਾਉਣਾ ਬਿਹਤਰ ਹੈ।

ਪਰ ਇਹ ਮੰਨਣ ਯੋਗ ਹੈ ਕਿ ਅੱਜ ਮੌਜੂਦ ਸਾਰੇ ਵਾਤਾਵਰਣ ਪ੍ਰਣਾਲੀ ਅਪੂਰਣ ਹਨ। ਇਸ ਲਈ, ਜੇਕਰ ਕੰਪਨੀ ਵਿੱਚ ਅਜਿਹੇ ਪ੍ਰਸ਼ੰਸਕ ਹਨ ਜੋ RAML ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ "ਇਹ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਲਚਕਦਾਰ ਢੰਗ ਨਾਲ ਵਿਚਾਰ ਪ੍ਰਗਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ," ਜਾਂ, ਇਸਦੇ ਉਲਟ, ਸਵੈਗਰ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ "ਇਹ ਸਪੱਸ਼ਟ ਹੈ," ਉਹਨਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਛੱਡਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ। ਉਹ ਕੀ ਹਨ ਉਹ ਇਸ ਦੇ ਆਦੀ ਹਨ ਅਤੇ ਚਾਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਕਿਸੇ ਵੀ ਫਾਰਮੈਟ ਦੇ ਟੂਲ ਨੂੰ ਫਾਈਲ ਨਾਲ ਸੋਧ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਾਡੇ ਤਜ਼ਰਬੇ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਪੋਸਟਾਂ ਵਿੱਚ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਕਿ ਅਸੀਂ ਸਾਡੇ RAML-Swagger ਆਰਕੀਟੈਕਚਰ ਦੇ ਅਧਾਰ ਤੇ ਕਿਹੜੀਆਂ ਸਥਿਰ ਅਤੇ ਗਤੀਸ਼ੀਲ ਜਾਂਚਾਂ ਕਰਦੇ ਹਾਂ, ਨਾਲ ਹੀ ਅਸੀਂ ਕੰਟਰੈਕਟਸ ਤੋਂ ਕਿਹੜੇ ਦਸਤਾਵੇਜ਼ ਤਿਆਰ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਸਭ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਕੰਟਰੈਕਟਸ ਨੂੰ ਐਨੋਟੇਟ ਕਰਨ ਲਈ ਤੁਸੀਂ ਕਿਹੜੀ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ?

• RAML 0.8

• RAML 1.0

• ਸਵੈਗਰ 2

• OAS3 (ਉਰਫ਼)

• ਰੇਖਾ

• ਹੋਰ

• ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਿਹਾ

100 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਪਾਈ। 24 ਉਪਭੋਗਤਾ ਪਰਹੇਜ਼ ਰਹੇ।

ਸਰੋਤ: www.habr.com