(Migrated) REST and Query parameter within an Outbound connection

Community support
#1

(This message has been automatically imported from the retired mailing list)

Hello all,

I am confused on how to incorporate both REST and URL/Query parameters into
a single outbound connection.

Right now my connection URL looks like this:

‘/permissions/user/{user_id}’

When I call this code:

‘response = conn.conn.get(self.cid, headers=headers, params={‘user_id’: self
.request.input[‘user_id’]})’

… the outbound connection successfully calls
’/permissions/user/rtsiomenko’.

However, I need to include a URL parameter at the end as well, so that the
URL that is called

is something like /permissions/user/rtsiomenko?format=JSON&type=internal

but I cannot find any documentation on how to do this?

Thanks,

Rostislav

#2

Dariusz,

Thanks for your reply - I looked at that page before and did not understand
that extra params would be moved to the URL path! It makes more sense now.

I do have another, slightly related question about URL parameters, since
we’re on that topic - for plain HTTP channels, not outbound connections. I
have read the docs on channels several times but still cannot understand
why I am getting this behavior:

Channel 1, url: /zato/permissions/user/{user_id}
Channel 2, url: /zato/permissions/user/{user_id}/update
Channel 3, url: /zato/permissions/user/{user_id}/group/{group_id}

Whenever I create channels with the above structures or similar, any calls
to channel 2 or 3 will always be “intercepted” by Channel 1, because Zato
will for some reason assume everything after /user/ is a {user_id}! So I
cannot create any meaningful URL patterns, as POSTing to something like
/zato/permissions/user/rtsiomenko/group/1234 will always route to Channel 1
with “rtsiomenko/group/1234” as the user_id parameter. I am sure that I’m
missing something here, but I tweaked all the possible settings for a
channel - merging URL params to reqs, URL params priority, Params priority

  • and still get this behavior. What is the correct way to deal with this?
    Thanks again!

Rostislav

On Mon, Feb 16, 2015 at 5:10 PM, Dariusz Suchojad dsuch@zato.io wrote:

On 16/02/15 21:12, Rostislav Tsiomenko wrote:

‘response = conn.conn.get(self.cid, headers=headers, params={‘user_id’:
self.request.input[‘user_id’]})’

… the outbound connection successfully calls
’/permissions/user/rtsiomenko’.

However, I need to include a URL parameter at the end as well, so that
the URL that is called

is something like
/permissions/user/rtsiomenko?format=JSON&type=internal

Hi Rostislav,

here’s a usage example:

https://zato.io/docs/progguide/rest/outconns.html

If the params dictionary contains elements that are found not be needed
in the URL path, they will be provided to the target system in query
string.

In your example, given the path:

/permissions/user/{user_id}

and params

{‘user_id’:‘my-user’, ‘format’:‘JSON’, ‘type’:‘internal’}

the net result will be

/permissions/user/my-user?format=JSON&type=internal

#3

On 16/02/15 21:12, Rostislav Tsiomenko wrote:

‘response = conn.conn.get(self.cid, headers=headers, params={‘user_id’:
self.request.input[‘user_id’]})’

… the outbound connection successfully calls
’/permissions/user/rtsiomenko’.

However, I need to include a URL parameter at the end as well, so that
the URL that is called

is something like /permissions/user/rtsiomenko?format=JSON&type=internal

Hi Rostislav,

here’s a usage example:

https://zato.io/docs/progguide/rest/outconns.html

If the params dictionary contains elements that are found not be needed
in the URL path, they will be provided to the target system in query string.

In your example, given the path:

/permissions/user/{user_id}

and params

{‘user_id’:‘my-user’, ‘format’:‘JSON’, ‘type’:‘internal’}

the net result will be

/permissions/user/my-user?format=JSON&type=internal

#4

On 17/02/15 04:48, Rostislav Tsiomenko wrote:

Channel 1, url: /zato/permissions/user/{user_id}
Channel 2, url: /zato/permissions/user/{user_id}/update
Channel 3, url: /zato/permissions/user/{user_id}/group/{group_id}

Whenever I create channels with the above structures or similar, any
calls to channel 2 or 3 will always be “intercepted” by Channel 1,
because Zato will for some reason assume everything after /user/ is a
{user_id}!

Hi Rostislav,

this is done and will be released in 2.0.6 the next week so that the
workaround described here won’t be necessary now:

https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2015-February/000885.html

Since 2.0.6, if you have channels like the ones here…

#1 /user/{user_id}
#2 /user/{user_id}/update
#3 /user/{user_id}/update/{group_id}

… then /user/123/update will match #2 with the user_id being '123’
instead of #1 with ‘123/update’.

Likewise /user/123/group/456 will match #3 with correct user_id and
group_id instead of #1 with user_id ‘123/group/456’