aplopio / django_rip Goto Github PK

Serialising entity with missing keys for non required fields throws exception.

RIP was developed and tested against a system where every api call has authentication associated with it. This is a very narrow generalization for an open source library. The authorization by default is no authorization. The authentication must also use the same pattern

I have a schema like so

class ProfileDataSchema(ApiSchema):
    name = fields.StringField(required=True)
    value = fields.StringField(required=True)

I am using

class CandidateSchema(ApiSchema):
    id = fields.IdField()
    profile_data = fields.ListField(field=fields.SchemaField(of_type=ProfileDataSchema))

Here the profile data should be an array of dicts with keys name and value.
When I pass some value that does not match this schema, the default schema validator throws up a 500 error instead of a more meaningful error code.

rip's __init__.py is empty. As a result Text Editors, IDE, Shell programs are unable to give suggestions on rip.. This can be fixed by importing relevant items in __init__.py.

In [14]: dir(rip)
Out[14]: ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__']

In [15]: import requests

In [16]: dir(requests)
Out[16]:
['ConnectionError',
 'HTTPError',
 'NullHandler',
 'PreparedRequest',
 'Request',
 ...
 'utils']

A good example for this is requests, https://github.com/kennethreitz/requests/blob/master/requests/__init__.py

The rip.Request init function today looks like this

def __init__(self, user, request_params, data=None, context_params=None,
                 request_headers=None, request_body=None):

Find the odd man out. Not so hard was it. Other than user, everything else is sort of one to one with an http request. User however is a django abstraction that got leaked into the Request object.
Other frameworks may have similarly named or differently named abstractions. That is why it belongs to the request.context_params dictionary

We currently depend on pyhamcrest for test assertions in most places. This was a hangover from the pre py.test days. All tests should now use python asserts.

If a query parameter has/is URL encoded. When the value is extracted from the parameters it is not URL decoded. Example:

https://example.com/api/v1/something/?param=with%20encoding

will extracted value for param field without decoding the string.

Today there is no way for me to know that a green build on Travis is actually green when I integrate rip with its clients. Therefore we need to write Django specific integration tests that can give immediate feedback.

There is an issue however to move the django adapter to another repo. If that issue gets done first, then the tests go into that repository.

Today the way to register APIs is to give it a leading name and version number which is kind of hardcoded.

api = Api(name='api', version='v1')

This translates to
api/v1/xxx
Both name and version should be optional.
Ideally it should be root accessible / without a version number

For example

api = Api(name='api', version='')  #/api/xxx
api = Api(name='', version='')      # /
api = Api(name='', version='v1')  # Nah maybe not

RIP has virtually zero documentation. Fix it !

For the fields inherited from StringField return true if value is DEFAULT_FIELD_VALUE

• UrlField
• EmailField
  & for ChoiceField

Currently, if we don't specify a content-type (esp. for POST/PATCH) requests , then we receive a 500 because the request data is not set. Ideally, it should return HTTP 415 error.

RIP test doesn't pass against Python version 2.6 and 3.3 +. Contributing guidelines says 2.6, 2.7, 3.3, 3.4 are supported and test should pass. Either fix the docs or fix tests.

I am raising this issue as a platform to discuss the following topics:

• How to document RIP ?
• Which tool to use.
• Using document generators ?
• Or do we write external documentation.
• Marking parts are considerably stable so that we can start documenting them.

If you have any other point to raise, please do so.

Scenario -

Update multiple objects for resource in single go.

1. GET - list
2. CREATE - list
3. UPDATE - list
4. CREATE_OR_UPDATE - list (like an upsert)

4 is a nice to have. While 2 and 3 are what's missing today. The way to do this today is to write a CrudResource for GET and a CommandResource for the others.

Today we have only one implementation of a Resource i.e. CrudResource
Sometimes we need to an endpoint that just returns data, without CRUD semantics

For example, /api/v1/client_metadata/ (and not /api/v1/client_metadata/1/)
It should return the whatever schema I like it to return

RIP is a framework written modularly enough to accommodate different web frameworks like flask.
The version as of today is written with just the django adapter. What this means is that RIP has a pip dependency on django.

We need to separate out the django adapter into a separate repo, it becomes easier to add newer adapters.

Sometimes we need an API endpoint that just supports a POST or a command in CQRS terms.
Today we have a hack that people use which looks like the following

class CommandResource(CrudResource):
    allowed_actions = [CrudActions.CREATE_DETAIL]
    serializer_cls = CommandSerializer

This is not the optimal way of doing it because the authorization step in the pipeline follows the conventions of the CrudResource. i.e. the authorization step says

  def authorize_create_detail(self, request):
    pass

Whereas it should ideally be

 def authorize_command(self, request):
    pass

In pypi/support#74 it has been requested to transfer the PyPI project https://pypi.org/project/rip/ to a different user. This github repository is linked from the project description. Based simply on name and GitHub profile, it appears that @greasematic may be the PyPI project owner. Could an owner of this repository or the PyPI project please respond to that issue?

Important: If the PyPI moderators are unable to establish contact within 6 weeks, the project may be considered abandoned and transferred.

E.g. For a GET request sending false or False in the request body should automatically convert it to python False in the kwargs to the read_list method

RB.stages.fetch({ is_prospecting: false})

def read_list(self, request, kwargs):
    #  where kwargs['is_prospecting'] should be False and not u'false'

Things can get complex when we have an object graph instead of a single flat object. So we can at least do this for the first level of simple data types

We need ChoiceField to specify list of allowed values. These allowed values needn't be of same type.