Time  Nick             Message
09:05 daxim            typical selfish jerk ass software authors, no comparison with existing pathing implementations (notably JSON Path)
09:15 trygvis          hm, it's more a query language than path expressions
09:18 trygvis          it seems to have a fairly good specification too
09:18 trygvis          it's at least not like your average json-based api crap
11:17 kype             is it possible to use Restful api as a communication mechanism between two programs? Eg. Program A transfers a large string data to the Program B, Program B processes it and then returns back some result to Program A
11:20 Jarda            of course it is possible to create such 'ping back' using REST
11:22 Jarda            but I would do it so that I would return 202 Accepted with a link back what Program A can use to check for the operation status
11:22 kype             Err
11:23 kype             Im still new to this, but its possible to define the result in JSON file and then send the result back to Program A
11:23 Jarda            oh of course it is
11:23 Jarda            I thought it was some heavy operation that the client (Program A) could not wait for
11:23 Jarda            but that's very standard: Send some data over HTTP and get a response back
11:23 Jarda            the response can be in any form
11:24 kype             nah its some light operation. But from what im reading data is usually sent in the url i.e http://localhost/api/mystring, so if i want to send a large string, my url is going to be super long?
11:24 Jarda            no, data is normally sent as the request body in a POST or PUT operation
11:25 kype             Ah okay got that, cool thanks
12:10 ironChicken      kype: i would say that REST is not necessarily a good method of IPC
12:10 ironChicken      also, don't forget that REST != HTTP
12:11 kype             ironChicken: Why so? Because it allows the components to be modular, unlike using something like jython libraries to use java libraries in python
12:11 ironChicken      in REST, you really need to have a clear reason for one component to be the 'server' and the other component to be the 'client'
12:12 ironChicken      kype: i don't follow your analogy?
12:13 kype             ironChicken: Yes i do have one program being the client and another being the server ... i.e Program B provides services which Program A consumes
12:13 ironChicken      ok, so that immediately makes REST a candidate
12:14 ironChicken      so program B knows about states and their transitions
12:14 ironChicken      and program A can get transitioned from one state to another based on how program B tells it to
12:15 ironChicken      and whether you use HTTP as the communications protocol is up to you
12:21 kype             Yes that is why i was looking at REST, which seemed like an easy way to achieve comms between two applications.
12:27 ironChicken      well, it's more like HTTP is the easy way to achieve comms
12:28 ironChicken      REST is how you discipline yourself to constrain what you communicate over that protocol
18:01 captain_furious_ if you have multiple customers that use a system but they all access the same type of resources would a a URL such as /api/
18:02 captain_furious_ or would you just use /api/
18:02 captain_furious_ and have the customer determined by the fact that theyt had to authenticate and so a session would be retrieved on each request
18:10 whartung         not sure I'm following you captain_furious_
18:10 whartung         are you talking about a multi-tenant application?
18:10 captain_furious_ yes, sorry multi tenant
18:11 whartung         you don't need a session to have customer meta data, you can just look it up based on their authentication
18:31 Jarda            yeah I use OAuth2 tokens and the token contains the 'environment id'
18:37 whartung         yea that'll work