Metadata-Version: 2.0
Name: pyramid-georest
Version: 3.0.13
Summary: pyramid_georest, extension for pyramid web frame work to provide rest interface for sql-alchemy mappers
Home-page: https://github.com/vvmruder/pyramid_georest
Author: Clemens Rudert
Author-email: clemens.rudert@bl.ch
License: GNU General Public License
Keywords: web pyramid pylons rest sqlalchemy orm model geoalchemy
Platform: UNKNOWN
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python :: 2.7
Classifier: Framework :: Pyramid
Classifier: Topic :: Internet :: WWW/HTTP
Classifier: Topic :: Internet :: WWW/HTTP :: WSGI :: Application
Requires-Dist: pyramid
Requires-Dist: SQLAlchemy
Requires-Dist: shapely
Requires-Dist: dicttoxml
Requires-Dist: geoalchemy2
Requires-Dist: transaction
Requires-Dist: waitress
Requires-Dist: pyramid-debugtoolbar
Requires-Dist: zope.sqlalchemy
Requires-Dist: PyYAML
Requires-Dist: psycopg2
Requires-Dist: simplejson
Provides-Extra: testing
Requires-Dist: WebTest (>=1.3.1); extra == 'testing'
Requires-Dist: pytest; extra == 'testing'
Requires-Dist: pytest-cov; extra == 'testing'

Pyramid REST interface
======================

This little package gives shortcuts to create a restful api to database sources. It provides a url pattern to serve the
sources.
It is meant to be used in a pyramid web framework eco system. It uses pyramid and sqlalchemy logic as well. Its goal is
to extend the database usage in pyramid frameworks. This way, it will be possible to serve data sources from
different databases from a single pyramid application.
I used a simple class system to make this api as adaptable as possible.

Main features:

* read (json, geojson, xml) + filtering via json parameters - also for geographic attributes
* read one / show (json, geojson, xml)
* create one
* update one
* delete one
* data model description (json, geojson, xml) => This provides a description to implement client side forms bound to the underlying data.

Special thing of this api: It can serve geometric extension objects too (It's only limited by geoalchemy2).

Dependencies:
=============
* pyramid (tested with 1.7.3)
* SQLAlchemy (tested with 1.0.15)
* GeoAlchemy2 (tested with 0.3.0)
* Shapely (tested with 1.5.17)
* dicttoxml (tested with 1.7.4)
* simplejson (tested with 3.8.2)


Usage in a standard pyramid web app
-----------------------------------

The pyramid framework for web apps provides an easy way for including 
standalone packages in its eco system. To learn
more about that, please refer to the [extending guide](http://docs.pylonsproject.org/projects/pyramid//en/latest/narr/extending.html 'extending guide').

In a nutshell (inside the __init__.py of your pyramids project in the 
main method ):

Configure the services which you want to be served via this api. Look 
at the following example to see how: 

```python
   from pyramid_georest.lib.rest import Api, Service
   from application.model import TestModel
   def main(global_config, **settings):
      """ This function returns a Pyramid WSGI application."""
      config = Configurator(settings=settings)
      config.include('pyramid_georest', route_prefix='api')
      test_api = Api(
         'postgresql://postgres:password@localhost:5432/test',
         config,
         'test_api'
      )
      test_service = Service(TestModel)
      test_api.add_service(test_service)
      config.scan()
      return config.make_wsgi_app()
```

Calling the config.include method with the packages name will do some 
initializing stuff (Note that the optional
parameter 'route_prefix' can be used to set the restful interface below 
a fix name space. This may be helpful especially
in big applications).

Main concept
------------

The main goal of this library is to reduce the consumption of memory ,
url spaces and cpu usage. In big applications with a lot of services 
this is a real big problem. In this context we have some central points 
to take care of.

1. number of database connections
2. number of defined dedicated urls
3. adaptability of the several parts which a API consist of

Therefor this api ships with a mechanism which takes care of reusing 
database connections as long as their definition is exactly the same 
(we use the connections string for this as a key).
To reduce the number of constructed urls on server startup we have one 
global pattern which is able to match a requested url through its name 
to the requested service. So in normal mode you get an global space 
where you can bind api's to which you can bind services 
(standard mode).

However this might useful in the most cases. But often 
you have some bigger applications and it is necessary to do some more 
dedicated and more structured organization of api's and to this effect 
of the urls. Especially if you are using the possibility of pyramid 
plugins which you include in the pyramid way ([pyramid include](http://docs.pylonsproject.org/projects/pyramid/en/latest/api/config.html#pyramid.config.Configurator.include 'pyramid include')).
To achieve this we have implemented a flag (stand_alone) to create an 
api not in a global scope but in a stand alone way. This kind of api 
object creates its own url scope and will respect the route_prefix of 
the including application. This is much more flexible in big 
applications which have different scopes to use the rest api.

**One global API for the whole application**

To have an api which is assigned to the global scope you can use this 
code:

```python
   from pyramid_georest.lib.rest import Api, Service
   from application.model import GlobalModel
   def main(global_config, **settings):
      """ This function returns a Pyramid WSGI application."""
      config = Configurator(settings=settings)
      config.include('pyramid_georest', route_prefix='api')
      global_api = Api(
         'postgresql://postgres:password@localhost:5432/test',
         config,
         'test'
      )
      global_service = Service(GlobalModel)
      global_api.add_service(global_service)
      config.scan()
      return config.make_wsgi_app()
```

Of cause it is possible to add as many services to your api object. But 
it is also possible to create an arbitrary number of apis.
In a simple stand alone pyramid application this might be the way you 
like to go.

Looking at the code above you will get an api which is running under 
the prefix '/api/' and with the name 'test'.
So you will find each service bound to this api under /api/test/...

Note that each api created this way will have the route prefix of the 
global scope!

**One dedicated API for a specific plugin**

If you have some plugin which you like to include in your pyramid 
application (cause this is the most generic way you can extend pyramid) 
you probably like to have a restful api dedicated to this plugin in 
matter of url spaces and naming. The code to achieve this might look 
like the following:

In your main pyramid application:

```python
   def main(global_config, **settings):
      """ This function returns a Pyramid WSGI application."""
      config = Configurator(settings=settings)
      config.include('pyramid_georest', route_prefix='api')
      config.include('my_plugin', route_prefix='my_plugin')
      config.scan()
      return config.make_wsgi_app()
```

In your plugins includeme mehtod:

```python
   from pyramid_georest.lib.rest import Api, Service
   from my_plugin.model import PluginModel
   def includeme(config):
      dedicated_api = Api(
         'postgresql://postgres:password@localhost:5432/test',
         config,
         'api',
         stand_alone=True
      )
      dedicated_service = Service(PluginModel)
      dedicated_api.add_service(dedicated_service)
```

Note the 'stand_alone' flag in api object creation!

Please note also that the route prefix in the include method is not 
mandatory but useful for the api created by this package.

Looking at the code above you will get an api which is running under 
the prefix '/my_plugin/' and with the name 'api'.
So you will find each service bound to this api under /my_plugin/api/...

**Combination of both**

Of cause it is possible to combine both:

```python
   def main(global_config, **settings):
      from pyramid_georest.lib.rest import Api, Service
      from application.model import GlobalModel
      """ This function returns a Pyramid WSGI application."""
      config = Configurator(settings=settings)
      config.include('pyramid_georest', route_prefix='api')
      config.include('my_plugin', route_prefix='my_plugin')
      global_api = Api(
         'postgresql://postgres:password@localhost:5432/test',
         config,
         'test'
      )
      global_service = Service(GlobalModel)
      global_api.add_service(global_service)
      config.scan()
      return config.make_wsgi_app()
```

```python
   from pyramid_georest.lib.rest import Api, Service
   from my_plugin.model import PluginModel
   def includeme(config):
      dedicated_api = Api(
         'postgresql://postgres:password@localhost:5432/test',
         config,
         'api',
         stand_alone=True
      )
      dedicated_service = Service(PluginModel)
      dedicated_api.add_service(dedicated_service)
```

This ends up in the following urls where you can find your services 
under.

The global one:
/api/test/...
The dedicated one:
/my_plugin/api/...


Pyramid REST Changelog
======================

## 3.0.13

* hanle NULL values for geometry

## 3.0.12

* set default value to None if it is a callable
* set srid automatically dependent on the model

## 3.0.11

* provide link between relationship and foreign key

## 3.0.10

* use srid from model definitions for write operations

## 3.0.9

* change urls with primary keys

## 3.0.8

* use a MANIFEST.in now

## 3.0.7

* bugfix the problem that bad requests weren't catched and iteration 
over dict was not correctly implemented

## 3.0.6

* bugfix to make the http methods for stand alone api configurable too 

## 3.0.5

* bugfix for add renderer problem, implement create, update, delete

## 3.0.4

* implement a flag which makes it possible to create global and 
dedicated api's for more flexibility.

## 3.0.3

* fix bug

## 3.0.2

* fix the add_view problem when rest api is included in other 
applications.

## 3.0.1

* fix the issue with geometric filtering
* make all geometric filter methods overwritable

## 3.0.0

* redesign complete behaviour (straight classes for more flexibility)
* redesign url creation
* complete independent api creation

## 2.0.4

Fixed issues:

* improve session handling
* use zope extension for sessions
* catch broad band errors to handle unknown behavior on db connections

## 2.0.3

Fixed issues:

* [#2](https://github.com/vvmruder/pyramid_georest/issues/2): Fixed problem where the relationship properties wasn't 
loaded correctly .

## 2.0.2

Fixed issues:

* [#2](https://github.com/vvmruder/pyramid_georest/issues/2): Fixed lost m to n handling.

## 2.0.1

Fixed issues:

* [#1](https://github.com/vvmruder/pyramid_georest/pull/1): Fixed encoding issue in filter parameter.

## 2.0.0

First usable version of this package (propably not pip save).

This version ships with the basic parts of REST and some updates which mainly belong to the sqlalchemy
session handling and the filtering system.


