I've been displeased with the way serialization & data preparation have been working. This splits them off into their own classes & makes them a bit pluggable. If I merge it, it'll be a major version bump (v2.0.0, though not much work to port), since fields is no longer special.

Thoughts? @jphalip @binarydud

This might be more of a question than a feature request or a bug report. I'm not sure :)

Currently, if the authentication fails then an Unauthorized exception is raised: https://github.com/toastdriven/restless/blob/1.0.0/restless/resources.py#L238-L239

When raised, this exception isn't handled, causing Django to return a 500 response. Wouldn't it be more appropriate for restless to directly return a 401 HTTP response instead? To do this I've overridden the handle() method to catch the exception. I'm not sure if that would be the recommended way.

Any thoughts? Thanks a lot for this great app by the way!

This allows passing a custom status to an endpoint HTTP response by using a tuple:

def update(self, pk):
    try:
        Post = Post.objects.get(id=pk)
        status = 200
    except Post.DoesNotExist:
        post = Post()
        status = 201
    
    post.title = self.data['title']
    post.user = User.objects.get(username=self.data['author'])
    post.content = self.data['body']
    post.save()
    return post, status   # status can be passed here

Fixes #118

I was going through the restless docs about extending restless. In the section about handling multiple forms of serialization around line 470 in the MultiSerializer example,

class MultiSerializer(Serializer):
        def deserialize(self, body):
            # This is Django-specific, but all frameworks can handle GET
            # parameters...
            ct = request.GET.get('format', 'json')
            if ct == 'yaml':
                return yaml.safe_load(body)
            else:
                return json.load(body)

        def serialize(self, data):
            # Again, Django-specific.
            ct = request.GET.get('format', 'json')
            if ct == 'yaml':
                return yaml.dump(body)
            else:
                return json.dumps(body, cls=MoreTypesJSONEncoder)

in line ct = request.GET.get.... Its not clear where the request variable being used is coming from. I experimented a little and realized that neither the serializer instance nor the supplied arguments contain the request instance.

Can you please clarify if I am missing something here - in which case we can just improve the docs around the same.

Also if the request instance is not really present, my ideas around making it available would be as follows

• make the resource instance available as Serializer.resource - so that it can be used as self.resource (I dont recommend this one since it makes too much of the details available to the serializer)
• make the request instance available as Serializer.request - so that it can be used as self.request - but this one can raise thread safety issues.

I would be happy to make the changes and raise PR for you if you would like that

I notice that request.data is not populated on GET requests because almost no HTTP clients send a request body with GET requests, even though some client libraries allow it. On the contrary, when clients want to pass data via GET, they (almost always) use querystring arguments. Wouldn't it make sense for restless to conditionally populate request.data from wherever the data is?

As a django-piston user, it is common to have nested data on the fields declaration:

fields = (
    'id', 'username',
    ('group', ('id', 'name'))
)

On django-tastypie, this is similar to use full = True on ForeignKey fields.

Is there a way to work with nested data?

What are your opinions about dropping support for Python < 3.4?

Python 2.7 is reaching end-of-life soon. And Python 3.0 to 3.3 are not supported anymore.

Maybe we could give an step foward and drop support for 3.4 too, because it's end of life will be in two months.

This will help us to support new versions of some frameworks while keeping the code clear.

django.conf.urls.patterns() is deprecated since Django 1.8 and removed in 1.10. It is imported however in dj.py. See https://docs.djangoproject.com/en/dev/releases/1.8/#django-conf-urls-patterns

Description

TornadoResource error handling is broken if tornado.web.Application is not run in debug mode.

During the handling of any error Resource.build_error() is called, which in turn calls TornadoResource.is_debug(). This will throw a KeyError if debug was not passed to the Application constructor. This is an optional parameter and should not be relied upon.

Example

A simple example displaying this error can be seen below

from tornado import web, ioloop
from restless.exceptions import BadRequest
from restless.tnd import TornadoResource

class TestTornadoResource(TornadoResource):
    def list(self):
        raise BadRequest()

# Fails to handle the `BadRequest` properly
# This will only work if debug=True/False is passed. 
app = web.Application([
    (r'/', TestTornadoResource.as_list())
])

if __name__ == '__main__':
    app.listen(8080)
    ioloop.IOLoop.instance().start()

Currently UUIDs fail both in that they can't be serialized and can't be used as a pk

I fould this pull request: https://github.com/toastdriven/restless/pull/49/files and notice that Django it self will support this in 1.8.4: https://docs.djangoproject.com/en/1.8/releases/1.8.4/

I've manually updated my urls to this:

    @classmethod
    def urls(cls, name_prefix=None):
        return patterns('',
                        url(r'^$', cls.as_list(), name=cls.build_url_name('list', name_prefix)),
                        url(r'^(?P<pk>[-\w]+)/$', cls.as_detail(), name=cls.build_url_name('detail', name_prefix)),
                        )

I'm not a regex wiz, so there might be a better one. Would love this to be build in.

I added a way to change the status code of a request. Currently you have the following options:

• Add a decorator to a function: @status(201)
• Create a data.Data object ```return data.Data('yourdata', status=201)

Change One: restless/restless/dj.py from django.conf.urls import url ❌ from django.urls import re_path ✔️

url(r'^$', cls.as_list(), name=cls.build_url_name('list', name_prefix)), ❌ re_path (r'^$', cls.as_list(), name=cls.build_url_name('list', name_prefix)), ✔️

url(r'^(?P<pk>[\w-]+)/$', cls.as_detail(), name=cls.build_url_name('detail', name_prefix)), ❌ re_path (r'^(?P<pk>[\w-]+)/$', cls.as_detail(), name=cls.build_url_name('detail', name_prefix)), ✔️

Change Two: Refactor codes

There are small typos in:

• docs/cookbook.rst
• docs/extending.rst
• docs/releasenotes/v2.0.0.rst
• docs/tutorial.rst
• restless/resources.py

Fixes:

• Should read overriding rather than overridding.
• Should read output rather than ouput.
• Should read grained rather than graned.
• Should read business rather than busines.

Semi-automated pull request generated by https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

The django.conf.urls.url function has been deprecated since version 3.1 and wil be removed on version 4. I replaced it with the easier to read path function.

Edit: I also added the support for Django 4.0 on tox and on Travis. I think this PR is important to make sure that people can update to later versions of Django without break anything.

When a user pass the p parameter in query, Django returns a string. The string needs to be casted to integer in order to be used in the paginator. Otherwise, the response returns BadRequest.

https://github.com/toastdriven/restless/blob/661593b7b43c42d1bc508dec795356297991255e/restless/exceptions.py#L36

Should be something like that:

self.msg = msg if msg else self.__class__.msg

Currently, you could be left with a circular import problem if your preparer references another preparer that hasn't been defined yet and you can't change the order of the preparers to fix it.

This is a bit like when Django references another model in a ForeignKey. The Django syntax lets you put the Model directly into the ForeignKey definition or a string that references the model.

I propose supporting this syntax 'choices': CollectionSubPreparer('choice_set.all', 'survey.api.choice_preparer'),

Notice the preparer is referenced as a string instead of including it directly. The change to CollectionSubPreparer is quite simple. Something like this:

from pydoc import locate

class MyCollectionSubPreparer(CollectionSubPreparer):
    """ Override this to allow for the preparer to be a dot notation string (i.e. survey.api.question_preparer).
    """

    def prepare(self, data):
        """
        Handles passing each item in the collection data to the configured
        subpreparer.
        Uses a loop and the ``get_inner_data`` method to provide the correct
        item of the data.
        Returns a list of data as the response.
        """
        result = []

        if isinstance(self.preparer, str):
            self.preparer = locate(self.preparer)

        for item in self.get_inner_data(data):
            result.append(self.preparer.prepare(item))

        return result

I can prepare a PR that changes CollectionSubPreparer if there's interest in this change.