JSON RPC client for iPhone/iPad

[Lautaro]

We're working on a JSON RPC client for iOS:

http://code.google.com/p/oxeniphonecommons/wiki/JsonComponents

It uses proxies in order to allow transparent access.

If somebody wants to use it, feel free to do that. It's open. Any help
in development is welcome too :)

[Matthew Morley]

How are you finding using json-rpc with iOS?

--
Matt (MPCM)

[Lautaro Brasseur]

It works very well. However, we just tried it with a mock service written using jsonrpc4j (the final product will run against a .NET backend).

We had some problems with dates (NSDate class) since JSONKit doesn't handle them, but we solved these problems by converting them to strings (NSString).

Also wer'e thinking in adding a "sessionId" field to the message, in order to maintain a session with the service. JSON-RPC doesn't has a specific field for this, right? Also we evaluated using cookies (just like most HTTP sessions), but using a JSON field seems more clear and transport independent.

2011/10/11 Matthew Morley <mmo...@mpcm.com>

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Matt (MPCM)]

There is no field in the spec to imply session/token.

I'd recommend handling in the transport if possible, otherwise you can
always use a handler that strips it out as a listed param or a name
spaced method identifier. Lots of ways to address it depending on your
needs and how your api is setup, and how much you really need it to be
transport agnostic.

[Stuart Reynolds]

Hi Matt,

I've just hit a similar design decision. We're just starting down a route where the session ids is a message parameter.

I'd be curious to know the benefits of doing this at the transport layer.

Here's our situation (similar but different):

 - the bulk of our method calls relate to personal data, and need to be traceable to some password authority.

so,

 - the client needs to get auth_token at login

 - all calls are over HTTPS. A session might be:

      auth_token,user_id = login( username, pass )

      addAddress( auth_token, user_id, address )

      - validates auth_token is owned by the supplied userId.

      - prevent a client for tweaking the userId and modifying records for other users.

  

In our server code I'm expecting that we can easily build a wrapper that performs the following transform:

 (1) For each server method:  f( auth_token, args... )   --> 

    {

       if !valid( auth_token ) raise rpc_error(auth)

       f'( args... )  # call the method, 

    }

 (2) For each server method: f( auth_token, user_id, args... )   --> 

    {

       if !valid_for_user( auth_token, user ) raise rpc_error(auth)

       f'( user_id, args, ... )  # call the method, 

    }

... in order to remove the need to perform auth checks in the body every method call. 

(Tiny RPC makes this very easy by using decorators.)

So, we've removed session_ids and can use the auth_token in its place. The auth_token also tracks the session.

My question is, what there benefits to having session IDs (or auth_tokens) visible-to/handled-in the transport layer?

Cheers,

- Stuart

[Skylos]

On Fri, Jul 12, 2013 at 11:45 AM, Stuart Reynolds <stuart....@gmail.com> wrote:

My question is, what there benefits to having session IDs (or auth_tokens) visible-to/handled-in the transport layer?

Not muddying up your method call parameter namespace with reserved words.

Reducing complexity by removing the need for the individual methods to assert the need for authorization.

Modularization by separating the concerns of authentication from authorization.

There probably are more, but thats what occurs to me off the cuff.

Skylos