Metadata-Version: 1.1
Name: django-rest-mock
Version: 0.2.6
Summary: Mock Express server generated based on your views, that can come in handy when developing REST APIs with Django
Home-page: https://github.com/thomasjiangcy/django-rest-mock-server
Author: Thomas Jiang
Author-email: thomasjiangcy@gmail.com
License: MIT
Description-Content-Type: UNKNOWN
Description: Django REST Mock
        ================
        
        Mock Express server generated based on your views, that can come in handy when developing REST APIs with Django.
        
        Typically, the Django developer can first create all the views with docstrings and pass on the project to the front-end developer who can work with the mock server which outputs what is already expected. This allows frontend devs to work with a stable and predictable API.
        
        
        Requirements
        ============
        Requires Django 1.11 or later and Node.js.
        
        Note that this requires views to be Class-based Views.
        
        
        Installation
        ============
        
        Using pip::
        
            $ pip install django-rest-mock
        
        
        Then include ``rest_mock_server`` into your ``INSTALLED_APPS``::
        
            INSTALLED_APPS = (
                ...
                'rest_mock_server',
                ...
            )
        
        
        Usage
        =====
        
        After including docstrings for the views you wish to generate endpoints for, you may run the following commands
        
        Generates an ExpressJS file::
        
            $ python manage.py genmockserver
        
        Starts an ExpressJS server (it will generate an ExpressJS file if necessary)::
        
            $ python manage.py startmockserver
        
        
        Syntax
        ======
        
        1. Basic endpoint::
        
            class SomeView(APIView):
                """
                URL: /some-view/
                """
        
                def get(self, request, *args, **kwargs):
                    """
                    ```
                    {
                        "data": "Hello, world!"
                    }
                    ```
                    """
                    pass
        
        
        2. RESTful endpoint with list & instances::
        
            class ResourceListView(ListCreateAPIView):
                """
                URL: /resource/__key
                """
        
                def post(self, request, *args, **kwargs):
                    """
                    ```
                    {
                        "__options": {
                                "excludeKey": true
                        },
                    }
                    ```
                    """
                    pass
        
            class ResourceView(RetrieveUpdateDestroyAPIView):
                """
                URL: /resource/__key
                """
        
                def get(self, request, *args, **kwargs):
                    """
                    ```
                    {
                        "__key": "<id:int>",
                        "__key_position": "url",
                        "__mockcount": 5,
                        "__options": {
                            "modifiers": ["patch", "put", "delete"],
                            "excludeKey": false
                        },
                        "id": "<int>",
                        "name": "<name>",
                        "complexStructure": [
                            {
                                "link": "<int::10>",
                                "url": "<uri>",
                                "related_user": {
                                    "id": "<int:1:5>",
                                    "hash": "<sha256>"
                                }
                            }
                        ]
                    }
                    ```
                    """
                    pass
                
                def put(self, request, *args, **kwargs):
                    """We won't need to specify any response here"""
                    pass
                
                def patch(self, request, *args, **kwargs):
                    """We won't need to specify any response here"""
                    pass
                
                def delete(self, request, *args, **kwargs):
                    """We won't need to specify any response here"""
                    pass
        
        When creating fixtures for a resource (CRUD), you only need to work with the instance endpoint, in ``Django REST framework``, it's typically the endpoint that requires a unique ID - e.g. ``/some-resource/<pk>``
        
        You need to specify ``__key`` in the url and also in the response as above. The value follows the following syntax ``<name-of-unique-key:data-type>``.
        You will also need to specify the position of the key: either ``url`` or ``query``. If it is ``url``, it exists as a URL param, and ``query`` means that the key should be found in query string.
        
        * ``__mockcount``: (defaults to 1) Represents the number of instances of this fixture to create
        * ``__options``: Possible options related to this endpoint:
        * ``modifiers``: a list of modifier methods allowed for this resource. If you don't specify a method, that method won't be allowed for that endpoint
        * ``excludeKey``: this can be specified to exclude a method from matching ``__key`` in the url. E.g. for the POST method for ``/resource/``, you might want to exclude it
        
        The syntax for fake data is as follows: ``<fakedatatype:min:max>``
        
        * ``fakedatatype`` is any attribute that can be generated by `Faker <https://faker.readthedocs.io/>`_
        * ``min``: for numbers, it will only generated random numbers that are at least ``min`` or greater. For strings, this will be the first index it will slice from
        * ``max``: for numbers, it will only generated random numbers that are at most ``max`` or smaller. For strings, this will be the last index
        
        
        POST requests will not create new instances, but PUT, PATCH and DELETE will work as expected on the resources.
        The resources are reset everytime the server is restarted.
        
        
        Meta-Keys
        =============
        
        As you have probably seen in the examples above, there are special keys prefixed with double-underscores such as ``__key``. These are meta-keys which will be used to grant special properties to the mock responses.
        
        * ``__key``: Represents the primary key/unique identifier of an instance
        * ``__key_position``: Where the ``__key`` should be located in the url - there are only two options "url" or "query".
            * ``url``: The key should be within the main url such as ``/api/example/__key``
            * ``query``: They key should be within the params such as ``api/example?id[str]=__key``
        * ``__mockcount``: The number of instances to create. Note that if ``__key`` is specified, an endpoint will be created that lists all the individual instances. However, if no ``__key`` is specified, then the endpoint will just return an array of N instances where N is specified in ``__mockcount``
        * ``__relationships``: Relationships dictate simple relationships between items in the mock response. The syntax is always "<source__relationship__target>"
            * ``count``: It would be best illustrated with an example::
        
                    {
                        "__relationships": [
                            "user_count__count__users",
                        ],
                        "user_count": 20,
                        "users": [
                            {
                                "id": "<int::50>",
                                "user": "<name>"
                            }
                        ]
                    }
        
            * If you want to specify a source value without displaying it in the eventual endpoint, you may use the hidden syntax with a double-dash::
        
                    {
                        "__relationships": [
                            "--user_count__count__users",
                        ],
                        "--user_count": 20,
                        "users": [
                            {
                                "id": "<int::50>",
                                "user": "<name>"
                            }
                        ]
                    }
        * ``__options``: Possible options related to this endpoint are as follows
            * ``modifiers``: a list of modifier methods allowed for this resource. If you don't specify a method, that method won't be allowed for that endpoint
            * ``excludeKey``: this can be specified to exclude a method from matching ``__key`` in the url. E.g. for the POST method for ``/resource/``, you might want to exclude it
        
        
        Fixtures
        ========
        
        More often than not, you will need to load fixtures to populate the mock endpoints.
        
        We can load fixtures during generation by specifying the ``--fixtures`` flag:
        ``python manage.py genmockserver --fixtures data``
        
        Note that the folders must be direct parents. All files with ``.json`` extension will be taken into account.
        
        The syntax for that will be: "<key__from__filename>"
        
        If a file called ``users.json`` was loaded, then you can do::
        
            {
                "id": "<id__from__users>",
                "full_name": "<first_name__from__users> <last_name__from__users>",
                "contact": "<contact__from__users>"
            }
        
        The JSON files must follow Django's format of JSON fixtures and the fields must include the keys used in the mock response. So "id", "first_name", "last_name" and "contact" must all exist in the users fields.
        
        
        Example
        =======
        
        Refer to the example app for a detailed example.
        
Platform: UNKNOWN
Classifier: Framework :: Django
Classifier: Framework :: Django :: 1.11
Classifier: Framework :: Django :: 2.0
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Programming Language :: Python :: 3.6
Classifier: Topic :: Software Development :: Libraries :: Python Modules
