| Time |
S |
Nick |
Message |
| 00:02 |
|
|
begriffs joined #rest |
| 01:27 |
|
|
vipkilla joined #rest |
| 01:30 |
|
|
ChrisAnn_ joined #rest |
| 01:31 |
|
|
lemur_ joined #rest |
| 01:31 |
|
|
rickharrison_ joined #rest |
| 01:32 |
|
|
mamund_ joined #rest |
| 01:42 |
|
|
trygvis_ joined #rest |
| 01:42 |
|
|
gluegadget_ joined #rest |
| 01:43 |
|
|
gluegadget_ joined #rest |
| 03:17 |
|
|
tr3online joined #rest |
| 03:25 |
|
|
_ollie joined #rest |
| 04:13 |
|
|
tr3online joined #rest |
| 04:52 |
|
|
lemur joined #rest |
| 04:53 |
|
|
MasterPiece joined #rest |
| 05:56 |
|
|
talios joined #rest |
| 06:48 |
|
|
Andre-B joined #rest |
| 07:13 |
|
|
proteusguy joined #rest |
| 07:37 |
|
|
interop_madness joined #rest |
| 08:10 |
|
|
gluegadget joined #rest |
| 08:10 |
|
|
gluegadget joined #rest |
| 08:55 |
|
|
TWH joined #rest |
| 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 |
| 09:24 |
|
|
talios joined #rest |
| 09:54 |
|
|
shrink0r joined #rest |
| 10:13 |
|
|
mezod joined #rest |
| 11:00 |
|
|
Left_Turn joined #rest |
| 11:15 |
|
|
kype joined #rest |
| 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:18 |
|
|
t_dot_zilla left #rest |
| 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 |
| 12:29 |
|
|
proteusguy joined #rest |
| 12:38 |
|
|
fumanchu joined #rest |
| 13:11 |
|
|
Left_Turn joined #rest |
| 13:32 |
|
|
saml joined #rest |
| 13:48 |
|
|
foist joined #rest |
| 14:02 |
|
|
_ollie joined #rest |
| 14:43 |
|
|
ordnungswidrig joined #rest |
| 15:14 |
|
|
Mxyzpltk joined #rest |
| 15:34 |
|
|
ordnungswidrig joined #rest |
| 15:49 |
|
|
ralphschindler joined #rest |
| 16:03 |
|
|
digitalsanctum joined #rest |
| 17:30 |
|
|
foist joined #rest |
| 17:45 |
|
|
ph88 joined #rest |
| 17:54 |
|
|
captain_furious_ joined #rest |
| 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 |
| 18:55 |
|
|
ralphschindler_ joined #rest |
| 20:33 |
|
|
talios joined #rest |
| 20:56 |
|
|
shrink0r joined #rest |
| 22:47 |
|
|
ralphschindler joined #rest |
| 23:19 |
|
|
Mxyzpltk joined #rest |
| 23:24 |
|
|
fumanchu_ joined #rest |
| 23:39 |
|
|
fumanchu joined #rest |
| 23:53 |
|
|
begriffs joined #rest |
| 23:55 |
|
|
fumanchu_ joined #rest |
