pyramid-georest 3.0.14

pyramid_georest, extension for pyramid web frame work to provide rest interface for sql-alchemy mappers

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.14

* improve output for geojson format
* now it is possible to send data as geojson for create and update services

## 3.0.13

* handle 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.