Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Implementation of the new REST API for Open Source LBS-platform Geo2Tag

330 views

Published on

Open Source LBS engine description. New REST API inroduction

Published in: Technology
  • Hello there! Get Your Professional Job-Winning Resume Here! http://bit.ly/topresum
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Implementation of the new REST API for Open Source LBS-platform Geo2Tag

  1. 1. Implementation of the new REST API for Open Source LBS-platform Geo2Tag Mark Zaslavskiy, ITMO University, Fruct Ltd. Dmitry Mouromtsev, ITMO University. 1
  2. 2. Introduction and initial state • Geo2Tag is an OpenSource LBS-platform – open backend for geo- and geocontext services. • Existing sources are written in C++ with PostgreSql as a data storage. • Platform development is performed using crowdsourcing model: ▫ Students of various IT departments do most of the work. ▫ Professional developers provide process control. 2
  3. 3. Challenges •Encourage usage of the platform by 3rd party developers. •Simplify existing sources for better understanding by students. 3
  4. 4. Solution • Solution: ▫ Rewrite API and backend to be more understandable and maintainable. ▫ Add instruments for platform customization and data import. • Tasks ▫ Change API to be more RESTful:  Resource-based API URLs;  Support of paginated requests;  Data visualization;  OAuth authorization;  Plugin system ( = background data processing). ▫ Change backend to Python, due to portability and easier support. ▫ Change data storage to MongoDb due to built-in georequests and flexible collection structure. 4
  5. 5. Use case 5
  6. 6. Db structure • MasterDb: ▫ metadata, ▫ service data, ▫ users, ▫ instance logs. • Service db: ▫ channels, ▫ points, ▫ service logs. 6
  7. 7. REST API • resource-based urls • pagination support – all queries which produce lists where extended with number and offset parameters • all platform entities (services, points, channels, users, plugins) where made identifiable • examples: ▫ curl -b 'cookiefile.cookie' -X GET 'http://geomongo/instance/service/testservice/c hannel?number=10&offset=0‘ ▫ curl -b 'cookiefile.cookie' -X DELETE 'http://geomongo/instance/service/SERVICE_N AME' 7
  8. 8. OAuth2 authorization support • Old API was trying to perform full stack of user registration and it cause a lot of actions must be done by instance administrator. • Solution: ▫ Only OAuth2 authorization. ▫ During the authorization user account is created in case of first login and identifier is stored in an encrypted cookie. ▫ Google and Facebook as OAuth providers with ability of fast addition of other providers. 8
  9. 9. Data visualization 9
  10. 10. Data visualization 10
  11. 11. Plugins • Plugin is an extension for Geo2Tag REST API isolated inside /<prefix>/plugins/ resource. • Plugins are deployed as pep8-comparable python packages which match Geo2Tag interfaces. • Plugins are installed by instance administrator. 11
  12. 12. OpenData import • Goal: demonstrate how Geo2Tag plugins can be used and add ability to high level import of data into the platform. • Solution: built-in general interfaces for OpenData import plugin development: ▫ Data acquiring/parsing/importing classes. ▫ Interfaces for keeping references between imported data and sources. ▫ Import versioning interfaces. ▫ Wrapper around Geonames geocoder for Open Data without geographical coordinates. 12
  13. 13. OpenKarelia import plugin • Import of digital museum objects from OpenKarelia information system http://openkarelia.org/ • Plugin retrieves name, image, brief description, date information. • Interval dates are converted from OpenKarelia format to Geo2Tag format. 13
  14. 14. Conclusions • New API and backend with support of user-defined plugins. • For encouraging 3rd party developers OpenData import API was added • Future plans ▫ Web UI for administration. ▫ API for high level management of imported data. 14
  15. 15. Contacts • Mark Zaslavskiy, mark.zaslavskiy@fruct.org • Project resources: http://test.geo2tag.org/, http://geo2tag.atlassian.net/ • Demo server http://demo.geo2tag.org/ 15

×