explodinglabs / jsonrpcclient Goto Github PK

For example, rather than pip install 'jsonrpcclient[pyzmq]', use pip install 'jsonrpcclient[zeromq]'

Currently when logging the requests and responses, only certain attributes can be logged (such as the http headers). Give the ability to log any part, by passing the whole request/response object to the log method.

May not be possible, but I'd like to find out.

When calling TornadoClient.request, .send, .notify etc., allow passing a "done" callback to them, rather than adding callbacks to the return value.

Re #17

For consistency

These aren't useful - the user should have this information anyway. Remove in next major release.

It looks like the client notify() methods wait for a response from the server, however, the jsonrpc standard states that “The Server MUST NOT reply to a Notification”. Is this a bug in the client software?

Logging requires too much work on the end-user's part.

If the user hasn't configured logging, configure it for them.

Subclass Client with an AsyncClient class. It overrides send (and request and notify), with a coroutine version. It can then call _send_message as a coroutine.

Saves having to mess around with futures as seen in the TornadoClient.

Update TornadoClient to use the new AsyncClient class. Should look something like:

async def _send_message(self, request, **kwargs):
    response = await self.http_client.fetch(
        self.endpoint, method='POST', body=request, headers=headers, **kwargs)
    return self.process_response(response)

This is a breaking change because the current TornadoClient works with python 3.2, whereas using AsyncClient will limit to 3.5+.

Re #16

Should be straight forward, since pyzmq supports asyncio

Otherwise use aiozmq

Current name is poor style

For example:

Request.cat()

Copy the Server.getattr method to the Request class.

Ensure the deprecation warning is triggered upon importing the old server modules.

Aim for 100% code coverage.

Re #30

For more flexible subclassing of the Client class, refactor the send method.

Reason: Currently when a subclass overrides _send_message, it's required to log both the request and response. The parent class should do this work, with the subclass optionally adding extra details to include in the log entry.

Previously send was:

• send_message (subclass was required to log the request and response)
• process_response

New procedure:

• prepare_request (here the subclass can optionally add extra details to include in the request log entry)
• log_request
• send_message (here the subclass can optionally add extra details to include in the response log entry, after sending)
• process_response (includes logging the response)

Something like:

>>> from jsonrpcclient.http_client import request
>>> request('http://pets.com/', 'cat', name='Mittens')

It would instantiate a client for making a request, then throw it away.

http://www.jsonrpc.org/specification#batch

Rename Server._handle_response to _process_response.

Write a send() method which calls send_message, then passes the result/s to _process_response.

send() should accept either a string or dict (one request) or a list (batch).

Python versions prior to 2.7.9 require requests to be installed with requests[security].

Create a new extras_require key for those users.

Re #29

Add all protocol and framework examples on one page in documentation.

Proposing to rename the "server" modules and classes, to "client";

• HTTPServer becomes HTTPClient
• ZMQServer becomes ZMQClient
• TornadoServer becomes TornadoClient

Example code:

>>> from jsonrpcclient.http_client import HTTPClient
>>> HTTPClient('http://cats.com/').request('speak')

The plan would be to deprecate the old names by subclassing.

Duplicate code in these. Create a _log method which those other two call.

From:

pip install jsonrpcclient requests

To:

pip install 'jsonrpcclient[requests]'

Original comment by @saaj, here.

e.g.

>>> Request('get', request_id='id1')
{'jsonrpc': '2.0', 'method': 'get', 'id': 'id1')

Rather than hoping the client implementations log requests and responses, allow them to override logging methods, optionally. The requests and responses are logged regardless.

Some are using double

Hi,

it would be great if it's possible to pass arguments to requests to modify the SSL verification as described here: http://docs.python-requests.org/en/master/user/advanced/#ssl-cert-verification

Prepared requests can do this too: http://docs.python-requests.org/en/master/user/advanced/#prepared-requests

Thanks,
Timo

Currently there's no stable JSON RPC client for Tornado and Python3 in the Cheese Shop.

So always use double quotes when sending a JSON string.

And when serializing an object, use json.dumps() rather than str().

Currently the request-like methods return a primitive, normally the "result" part of the JSON-RPC response, such as "pong".

Instead, return an object of type Response. Some reasons to do this:

• Can hold more information about the response
• It's easier and more familiar for client classes to return Response(), rather than return self.process_response().

Down side would be, the user would have to use an attribute of the response (response.result or something) rather than just the raw return value. Edit: unless we override __new__ to set the object's value. Otherwise, Breaking change

Rather than at import time.

Original comment by @saaj, here.

To minimise the payload, shrink the json before sending.

Such as avro, protobuf, hpack, gzip

By adding a Server.validate_responses attribute

Sending a batch as one big json string works:

>>> client.send('[{"method": "ping", "id": 5, "jsonrpc": "2.0"}, {"method": "ping", "id": 6, "jsonrpc": "2.0"}]')

--> [{"method": "ping", "id": 5, "jsonrpc": "2.0"}, {"method": "ping", "id": 6, "jsonrpc": "2.0"}]
<-- [{"result": "pong", "id": 5, "jsonrpc": "2.0"}, {"result": "pong", "id": 6, "jsonrpc": "2.0"}] (200 OK)
[{'result': 'pong', 'id': 5, 'jsonrpc': '2.0'}, {'result': 'pong', 'id': 6, 'jsonrpc': '2.0'}]

But not as a list of json strings:

>>> client.send(['{"method": "ping", "id": 5, "jsonrpc": "2.0"}', '{"method": "ping", "id": 6, "jsonrpc": "2.0"}'])

--> ["{\"method\": \"ping\", \"id\": 5, \"jsonrpc\": \"2.0\"}", "{\"method\": \"ping\", \"id\": 6, \"jsonrpc\": \"2.0\"}"]
<-- [{"id": null, "jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}}, {"id": null, "jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}}] (200 OK)
[{'id': None, 'jsonrpc': '2.0', 'error': {'code': -32600, 'message': 'Invalid Request'}}, {'id': None, 'jsonrpc': '2.0', 'error': {'code': -32600, 'message': 'Invalid Request'}}]

Currently only http post and zeromq is supported.

Add a config option to disable these

It can be preferable to turn the log entries off, particularly for large batch requests

Such as send_message, log_request, log_response