మొదటి MySklad API 10 సంవత్సరాల క్రితం కనిపించింది. ఈ సమయంలో మేము API యొక్క ఇప్పటికే ఉన్న సంస్కరణలపై పని చేస్తున్నాము మరియు కొత్త వాటిని అభివృద్ధి చేస్తున్నాము. మరియు API యొక్క అనేక సంస్కరణలు ఇప్పటికే పాతిపెట్టబడ్డాయి.
ఈ కథనంలో చాలా విషయాలు ఉంటాయి: API ఎలా సృష్టించబడింది, క్లౌడ్ సేవకు ఇది ఎందుకు అవసరం, అది వినియోగదారులకు ఏమి ఇస్తుంది, మేము ఏ తప్పులు చేయగలిగాము మరియు మేము తర్వాత ఏమి చేయాలనుకుంటున్నాము.
నా పేరు ఒలేగ్ అలెక్సీవ్ , నేను MySklad యొక్క సాంకేతిక డైరెక్టర్ మరియు సహ వ్యవస్థాపకుడిని.
సేవ కోసం APIని ఎందుకు తయారు చేయాలి
మా క్లయింట్లు, పదివేల మంది వ్యవస్థాపకులు, క్లౌడ్ సొల్యూషన్లను చురుకుగా ఉపయోగిస్తున్నారు: బ్యాంకింగ్, ఆన్లైన్ స్టోర్లు, కమోడిటీ అకౌంటింగ్, CRM. మీరు ఒకదానికి కనెక్ట్ చేసిన తర్వాత, ఆపడం కష్టం. మరియు ఇప్పుడు ఐదవ, ఎనిమిదవ, పదవ సేవ వ్యవస్థాపకుడి పనిని సులభతరం చేస్తుంది, అయితే వినియోగదారులు ఈ క్లౌడ్ సేవల మధ్య డేటాను మానవీయంగా బదిలీ చేస్తారు. పని ఒక పీడకలగా మారుతుంది.
క్లౌడ్ సేవల మధ్య డేటాను బదిలీ చేసే సామర్థ్యాన్ని వినియోగదారులకు అందించడమే స్పష్టమైన పరిష్కారం. ఉదాహరణకు, ఫైల్ల రూపంలో డేటాను దిగుమతి చేయండి మరియు ఎగుమతి చేయండి, అది కావలసిన సేవకు అప్లోడ్ చేయబడుతుంది. ఫైల్లు సాధారణంగా ప్రతి సేవ యొక్క ఆకృతికి అనుగుణంగా మార్చబడతాయి. ఇది ఎక్కువ లేదా తక్కువ సాధారణ మాన్యువల్ పని, కానీ ఈ సేవల సంఖ్య పెరుగుదలతో, ఇది మరింత కష్టతరం అవుతుంది.
కాబట్టి, తదుపరి దశ API. దానితో, క్లౌడ్ సేవ ఒక సమయంలో అనేక సేవలను కనెక్ట్ చేసే వాస్తవం నుండి ప్రయోజనం పొందుతుంది. అటువంటి పర్యావరణ వ్యవస్థ యొక్క ఆవిర్భావం అదనపు అవకాశాల కారణంగా కొత్త వినియోగదారులను ఆకర్షిస్తుంది. కొత్త కార్యాచరణతో ఉత్పత్తి మరింత లాభదాయకంగా మరియు ఉపయోగకరంగా మారుతుంది.
మీరు మీ స్వంత ప్రోగ్రామింగ్ ఇంటర్ఫేస్లను సృష్టించినట్లయితే, ఇది APIకి ధన్యవాదాలు మీ ఉత్పత్తి గురించి తెలిసిన ప్రోగ్రామర్ల రూపంలో మూడవ పక్ష విక్రయ వ్యక్తులను ఆకర్షిస్తుంది. వారు ప్రతిపాదిత API ఆధారంగా పరిష్కారాలను రూపొందించడం ప్రారంభిస్తారు మరియు వారి కస్టమర్ల పనులను ఆటోమేట్ చేయడం ద్వారా డబ్బు సంపాదిస్తారు.
MySklad అకౌంటింగ్ సిస్టమ్ సాధారణ ప్రక్రియలపై ఆధారపడి ఉంటుంది. ప్రధాన విషయం ఏమిటంటే ప్రాథమిక పత్రాలతో పని చేయడం, వస్తువులను అంగీకరించడం మరియు రవాణా చేసే సామర్థ్యం మరియు ప్రాథమిక పత్రాల ఆధారంగా వ్యాపార నివేదికలను స్వీకరించడం. డేటా బదిలీ కూడా ఉంది, ఉదాహరణకు క్లౌడ్ అకౌంటింగ్కు మరియు బ్యాంకింగ్ సిస్టమ్లు లేదా రిటైల్ అవుట్లెట్ల నుండి దాని రసీదు. మేము ఆన్లైన్ స్టోర్లతో కూడా పని చేస్తాము: మేము ఉత్పత్తుల గురించి సమాచారాన్ని అందుకుంటాము మరియు బ్యాలెన్స్ల గురించి సమాచారాన్ని పంపుతాము.
MySklad యొక్క మొదటి API
APIతో పనిచేస్తున్న MySklad యొక్క 10 సంవత్సరాలలో, మేము డేటాను మార్పిడి చేసుకోవడానికి, బ్యాంకులతో పని చేయడానికి, చెల్లింపులు చేయడానికి మరియు బాహ్య టెలిఫోనీని ఉపయోగించడానికి అనుమతించే అన్ని రకాల ఇంటిగ్రేషన్లను పొందాము.
మొదటి సంవత్సరంలో, మేము ఏదైనా డేటాను XML ఆకృతిలో డౌన్లోడ్ చేయడాన్ని సాధ్యం చేసాము. అప్పటికి, వినియోగదారులు డేటాను ఆఫ్లైన్లో ఉంచడం చాలా స్పష్టంగా మరియు సర్వసాధారణంగా ఉండేది మరియు కొన్ని క్లౌడ్లో కాదు, మరియు మేము దానిని వారికి అందించాము. ఇంటర్ఫేస్ నుండి మాన్యువల్ ఎగుమతి ద్వారా అప్లోడ్ ప్రారంభించబడింది. అంటే, దీనిని ఇంకా API అని పిలవలేము.
అదే సమయంలో, మేము రుసాగ్రో కంపెనీతో సహకరించడం ప్రారంభించాము - వారు ఇప్పటికే ఉత్పత్తి మరియు అమ్మకాల ప్రణాళిక కోసం “వయోజన” ERPని ఉపయోగిస్తున్నారు, కాని వారు మైస్క్లాడ్లోని కర్మాగారాల్లో కార్లను లోడ్ చేయడాన్ని ఆటోమేట్ చేశారు. ఈ విధంగా మేము నిజమైన API యొక్క మొదటి మూలాధారాలను పొందాము: మా సేవ మరియు ERP మధ్య మార్పిడి అన్ని రకాల పత్రాలపై డేటాతో పెద్ద ఫైల్ను పంపడం ద్వారా జరిగింది.
బ్యాచ్ డేటా మార్పిడికి ఇది మంచి ఎంపిక, కానీ పత్రాలతో పాటు మేము వారి డిపెండెన్సీలను బదిలీ చేయాల్సి వచ్చింది: వస్తువులు, కాంట్రాక్టర్లు మరియు గిడ్డంగుల గురించి సమాచారం. అటువంటి డంప్ను ఎగుమతి చేసేటప్పుడు ఉత్పత్తి చేయడం అంత కష్టం కాదు, కానీ దిగుమతి చేసేటప్పుడు అన్వయించడం చాలా కష్టం, ఎందుకంటే మొత్తం సమాచారం ఒకే ప్యాకేజీలో వస్తుంది: కొత్త పత్రాల గురించి మరియు ఇప్పటికే ఉన్న వాటి గురించి.
మొదటి XML API ఎక్కువ కాలం జీవించలేదు - రెండు సంవత్సరాల తర్వాత మేము దానిని పునర్నిర్మించడం ప్రారంభించాము. దాని పని ప్రారంభంలో కూడా, సాఫ్ట్వేర్ ఇంటర్ఫేస్ను నిర్మించేటప్పుడు మేము అనేక తప్పులు చేసాము.
XML API ఎలా తయారు చేయబడింది: మా ఆర్కిటెక్ట్లలో ఒకరి నుండి ఉదాహరణ. మార్గం ద్వారా, అతని కథనాల కోసం వేచి ఉండండి.
ఇక్కడ మా ప్రధాన తప్పులు ఉన్నాయి:
- JAXB మార్కప్ నేరుగా ఎంటిటీ బీన్స్పై జరిగింది. మేము డేటాబేస్తో కమ్యూనికేట్ చేయడానికి హైబర్నేట్ని ఉపయోగిస్తాము మరియు అదే బీన్స్ కోసం JAXB మార్కప్ చేయబడింది. ఈ లోపం దాదాపు తక్షణమే కనిపించింది: డేటా నిర్మాణంలో ఏదైనా నవీకరణ APIని ఉపయోగించే ప్రతి ఒక్కరికీ అత్యవసరంగా తెలియజేయడం లేదా మునుపటి డేటా నిర్మాణంతో అనుకూలతను నిర్ధారించే క్రచ్లను రూపొందించడం అవసరం.
- API యాడ్-ఆన్గా పెరిగింది మరియు ఉత్పత్తిలో ఏ భాగమో మేము మొదట్లో నిర్వచించలేదు. API ఏదైనా ముఖ్యమైనదా, దాని మొదటి క్లయింట్ల కోసం వెనుకబడిన అనుకూలతను కొనసాగించడం అవసరమా అనే దాని గురించి కూడా వారు ఆలోచించలేదు. ఒకానొక సమయంలో, API వినియోగదారుల సంఖ్య చిన్న సంఖ్యలో 5% ఉంది మరియు వారిపై శ్రద్ధ చూపబడలేదు. ఒక సమయంలో చేసిన సార్వత్రిక వడపోత మాకు బ్యాకెండ్గా ఉపయోగించబడటానికి దారితీసింది. ఈ ఫిల్టరింగ్ GraphQL కాదు, కానీ అలాంటిదే - ఇది చాలా ప్రశ్న స్ట్రింగ్ పారామితుల ద్వారా పని చేస్తుంది. అటువంటి శక్తివంతమైన సాధనంతో, వినియోగదారులు ప్రతిఘటించడం కష్టం, మరియు అభ్యర్థనలు మాకు బదిలీ చేయబడ్డాయి, తద్వారా అవి నేరుగా వారి ఆన్లైన్ స్టోర్ల UI నుండి పంపబడతాయి. పరిస్థితి అసహ్యకరమైన ఆశ్చర్యాన్ని కలిగించింది, ఎందుకంటే అటువంటి సేవ యొక్క సదుపాయానికి వేర్వేరు ధర మరియు API యొక్క ఉత్పత్తిగా సాధారణంగా భిన్నమైన అవగాహన అవసరం.
- API ప్రధాన ఉత్పత్తిగా అభివృద్ధి చేయబడనందున, API డాక్యుమెంటేషన్ ఉత్పత్తి చేయబడి మరియు అవశేష ప్రాతిపదికన ప్రచురించబడింది - రివర్స్ ఇంజనీరింగ్ ద్వారా. ఈ మార్గం చాలా సరళంగా మరియు అనుకూలమైనదిగా అనిపిస్తుంది, కానీ ఇది ఒప్పందం ప్రకారం పనిచేయడానికి విరుద్ధంగా ఉంది. ప్రీసెట్ ఆపరేటింగ్ స్కీమ్తో నిర్దిష్ట భాగం ఉన్నప్పుడు ఇది జరుగుతుంది. డెవలపర్ ఈ పథకం మరియు విధికి అనుగుణంగా దీన్ని అమలు చేస్తారు, భాగం పరీక్షించబడుతుంది మరియు క్లయింట్ విశ్లేషకుల ఆలోచనకు సరిపోయే ఉత్పత్తిని అందుకుంటారు. రివర్స్ ఇంజనీరింగ్ కేవలం ఉనికిలో ఉన్న ఉత్పత్తిని మార్కెట్లోకి విసిరివేస్తుంది: అవసరమైన కార్యాచరణకు బదులుగా క్రచెస్, వింత పరిష్కారాలు మరియు సైకిళ్లతో.
- API ద్వారా వచ్చిన అభ్యర్థనల మొత్తం స్ట్రీమ్ Nginx లేదా అప్లికేషన్ సర్వర్ లాగ్ తప్ప మరేమీ కాదని విశ్లేషించవచ్చు. ఇది వినియోగదారులు మరియు సబ్స్క్రైబర్ల ద్వారా తప్ప సబ్జెక్ట్ ఏరియాలను గుర్తించడానికి మమ్మల్ని అనుమతించలేదు. అప్లికేషన్ లేదా క్లయింట్ రిజిస్ట్రేషన్ను నియంత్రించడానికి మార్గం లేకుంటే, పరిస్థితిని విశ్లేషించడం అసాధ్యం. ఈ సమస్య API అభివృద్ధిపై అతి తక్కువ ప్రభావాన్ని చూపింది; ఇది దాని ఔచిత్యం మరియు కార్యాచరణను అర్థం చేసుకోవడం గురించి మరింత ఎక్కువ.
ప్రయత్నం సంఖ్య రెండు: REST API
2010లో, మేము ఆన్లైన్ అకౌంటింగ్ - బుక్సాఫ్ట్తో మార్పిడి వ్యవస్థను రూపొందించడానికి ప్రయత్నించాము. టేకాఫ్ చేయలేదు. కానీ ఏకీకరణ ప్రక్రియలో, పూర్తి స్థాయి API కనిపించింది: REST మార్పిడి సేవ, ఇక్కడ RPC కాల్ల రూపంలో కార్యకలాపాలను యాక్సెస్ చేయడం వంటి స్వేచ్ఛలు లేవు. APIతో అన్ని కమ్యూనికేషన్లు విశ్రాంతి కోసం ప్రామాణిక మోడ్కి తీసుకురాబడ్డాయి: ప్రశ్న లైన్ ఎంటిటీ పేరును కలిగి ఉంటుంది మరియు దానితో నిర్వహించబడే ఆపరేషన్ http పద్ధతిని ఉపయోగించి పేర్కొనబడుతుంది. ఎంటిటీలు ఎప్పుడు అప్డేట్ చేయబడ్డాయి అనే దాని ఆధారంగా మేము ఫిల్టరింగ్ని జోడించాము మరియు వినియోగదారులు ఇప్పుడు వారి సిస్టమ్లతో ప్రతిరూపాన్ని రూపొందించుకునే అవకాశాన్ని కలిగి ఉన్నారు.
అదే సంవత్సరంలో, గిడ్డంగి మరియు జాబితా నిల్వలను అన్లోడ్ చేయడానికి API కనిపించింది. సిస్టమ్ యొక్క అత్యంత విలువైన భాగాలు API ద్వారా వినియోగదారులకు అందుబాటులోకి వచ్చాయి - ప్రాథమిక పత్రాల మార్పిడి మరియు నిల్వలు మరియు వస్తువుల ధరపై లెక్కించిన డేటా.
డిసెంబర్ 2015లో, RetailCRM మా APIని యాక్సెస్ చేయడానికి మొదటి థర్డ్-పార్టీ లైబ్రరీని ప్రచురించింది. ఇది చాలా చురుకుగా ఉపయోగించడం ప్రారంభమైంది, అయితే సేవ యొక్క ప్రజాదరణ మొత్తంగా పెరిగింది, API పై లోడ్ వెబ్ ఇంటర్ఫేస్పై లోడ్ కంటే వేగంగా పెరిగింది. ఒకరోజు పెరుగుదల లోడ్ సర్జ్గా మారింది.
మరియు ఈ జంప్, ఎడమ వైపున ఉన్న బాణం ద్వారా సూచించబడుతుంది, మా APIని అందిస్తున్న సర్వర్ను పూర్తిగా ఆశ్చర్యపరిచింది. ఈ లోడ్ని సరిగ్గా ఉత్పత్తి చేస్తున్నది ఏమిటో గుర్తించడానికి మేము ఒక వారం గడిపాము. క్లయింట్ ఫ్రంట్ల నుండి మా APIకి పంపబడిన అభ్యర్థనలు ఇవే అని తేలింది. దాదాపు 50 మంది కస్టమర్లు అన్నీ తిన్నారు. అప్పుడు మేము మా తప్పులలో ఒకదాన్ని గ్రహించాము - పరిమితులు పూర్తిగా లేకపోవడం.
ఫలితంగా, మేము ఏకకాల అభ్యర్థనల సంఖ్యపై పరిమితిని ప్రవేశపెట్టాము. ఇప్పుడు ఒక ఖాతా నుండి ఒకేసారి రెండు కంటే ఎక్కువ అభ్యర్థనలను తెరవడం సాధ్యం కాదు. బ్యాచ్ మోడ్లో డేటా మార్పిడి కోసం రెప్లికేషన్ మోడ్లో పని చేయడానికి ఇది సరిపోతుంది. మరియు మమ్మల్ని బ్యాకెండ్గా ఉపయోగించాలనుకునే వారు, ఆ క్షణం నుండి, వారు తమ సాఫ్ట్వేర్లో అనేక ఖాతాలపై పనిని ప్రవేశపెట్టినందున, టారిఫ్లను మెరుగ్గా పాటించవలసి వచ్చింది.
దానిని క్రమంలో ఉంచుదాం
ఇప్పటికే 2014 నుండి, ఇప్పటికే ఉన్న API కోసం డిమాండ్ వ్యాపారంలో ఒక ముఖ్యమైన భాగంగా మారింది మరియు API ఖాతాదారులతో డేటా మార్పిడిలో అత్యధిక డేటాను ఉత్పత్తి చేస్తుంది. 2015లో, మేము APIని క్లీన్ చేయడానికి ప్రాజెక్ట్ని ప్రారంభించాము. మేము XMLకి బదులుగా JSONని ఫార్మాట్గా ఎంచుకున్నాము మరియు మునుపటి సంస్కరణ అమలు సమయంలో గుర్తించబడిన లక్షణాల ఆధారంగా దీన్ని రూపొందించడం ప్రారంభించాము:
- సంస్కరణలను నిర్వహించగల సామర్థ్యం. ఇప్పటికే ఉన్న అప్లికేషన్ను ప్రభావితం చేయకుండా లేదా వినియోగదారు అనుభవానికి అంతరాయం కలిగించకుండా కొత్త సంస్కరణను అభివృద్ధి చేయడానికి సంస్కరణ మిమ్మల్ని అనుమతిస్తుంది.
- వినియోగదారు తాను స్వీకరించే ప్రతిస్పందనలోనే మెటాడేటాను చూడగల సామర్థ్యం.
- పెద్ద పత్రాలను మార్పిడి చేసే సామర్థ్యం. మేము 4-5 వేల కంటే ఎక్కువ స్థానాలతో పత్రాన్ని ప్రాసెస్ చేస్తే, ఇది సర్వర్కు సమస్యగా మారుతుంది: సుదీర్ఘ లావాదేవీ, సుదీర్ఘ http అభ్యర్థన. మేము పత్రాన్ని భాగాలుగా నవీకరించడానికి మరియు వాటిని సర్వర్కు పంపడం ద్వారా ఈ పత్రం యొక్క వ్యక్తిగత స్థానాలను నిర్వహించడానికి మిమ్మల్ని అనుమతించే ప్రత్యేక యంత్రాంగాన్ని రూపొందించాము.
- మునుపటి సంస్కరణలో ప్రతిరూపణ కోసం సాధనాలు కూడా ఉన్నాయి.
- లోడ్ పరిమితులు మునుపటి సంస్కరణలో అడుగుపెట్టిన రేక్ వారసత్వం లాంటివి. మేము నిర్దిష్ట వ్యవధిలో అభ్యర్థనల సంఖ్య, సమాంతర అభ్యర్థనల సంఖ్య మరియు ఒక IP చిరునామా నుండి అభ్యర్థనలపై పరిమితులను ప్రవేశపెట్టాము.
అప్పటి నుండి, మేము API యొక్క రెండు చిన్న వెర్షన్లను విడుదల చేసాము మరియు అనేక ప్రత్యేక APIలను ప్రారంభించాము, అయితే మొత్తం విధానం మారలేదు. అప్డేట్ చేయబడిన ఎక్స్ఛేంజ్ ఫార్మాట్ మరియు కొత్త ఆర్కిటెక్చర్ APIలోని లోపాలను చాలా వేగంగా సరిదిద్దడం సాధ్యం చేసింది.
MySklad API నేడు
నేడు, MySklad API అనేక సమస్యలను పరిష్కరిస్తుంది:
- ఆన్లైన్ స్టోర్లు, అకౌంటింగ్ సిస్టమ్లు, బ్యాంకులతో డేటా మార్పిడి;
- లెక్కించిన డేటా మరియు నివేదికలను పొందడం;
- క్లయింట్ అప్లికేషన్ల కోసం బ్యాకెండ్గా ఉపయోగించండి - మా మొబైల్ అప్లికేషన్లు మరియు డెస్క్టాప్ క్యాష్ రిజిస్టర్ API ద్వారా పని చేస్తాయి
- MySklad - webhooksలో డేటా మార్పుల గురించి నోటిఫికేషన్లను పంపడం;
- టెలిఫోనీ;
- విధేయత వ్యవస్థలు.
API ఆధారంగా, మా CEO Askar Rakhimberdiev నాలుగు గంటల్లో నేను API ద్వారా మిగిలిపోయిన వస్తువులను తీసివేసే టెలిగ్రామ్ బాట్ను వ్రాసాను:
ఇప్పుడు పొడి సంఖ్యలు.
పాత REST API కోసం మా గణాంకాలు ఇక్కడ ఉన్నాయి:
- 400 కంపెనీలు;
- 600 మంది వినియోగదారులు;
- రోజుకు 2 మిలియన్ అభ్యర్థనలు;
- 200 GB/రోజు అవుట్గోయింగ్ ట్రాఫిక్.
మరియు ఇక్కడ మేము అన్ని MySklad APIల కోసం ముందుకు వచ్చాము:
- 70 కంటే ఎక్కువ ఇంటిగ్రేషన్లు (వాటిలో కొన్నింటిని ఇక్కడ చూడవచ్చు );
- 8500 కంపెనీలు;
- 12 మంది వినియోగదారులు;
- రోజుకు 46 మిలియన్ అభ్యర్థనలు;
- 2 TB/రోజు అవుట్గోయింగ్ ట్రాఫిక్.
తదుపరి ఏమిటి
API అభివృద్ధి ప్రణాళికలు క్రియాశీల చర్చలో ఉన్నాయి. వినియోగదారులు మాకు అందించే ఆపరేటింగ్ అనుభవాన్ని పరిగణనలోకి తీసుకోవడానికి మేము ప్రయత్నిస్తాము. ప్రతిదీ ఒకేసారి చేయడం ఎల్లప్పుడూ సాధ్యపడదు, కానీ API యొక్క కొత్త వెర్షన్ మరింత సౌకర్యవంతమైన మెటాడేటా మరియు తక్కువ మెత్తటి నిర్మాణం, ప్రామాణీకరణ కోసం OAuth మరియు ఇంటర్ఫేస్లో రూపొందించబడిన అప్లికేషన్ల కోసం APIతో మూలన ఉంది.
MySkladతో ఇంటిగ్రేషన్ డెవలపర్ల కోసం మీరు ప్రత్యేక వెబ్సైట్లో వార్తలను అనుసరించవచ్చు: .
మూలం: www.habr.com
