| Time |
S |
Nick |
Message |
| 00:16 |
|
|
shrink0r joined #rest |
| 00:26 |
|
|
shrink0r_ joined #rest |
| 00:45 |
|
|
tohuw joined #rest |
| 00:45 |
|
|
tohuw left #rest |
| 01:23 |
|
|
lemur joined #rest |
| 01:41 |
|
|
shrink0r joined #rest |
| 01:47 |
|
|
tmoore joined #rest |
| 01:47 |
|
|
gluegadget joined #rest |
| 01:52 |
|
|
lebster joined #rest |
| 01:55 |
|
|
rickharrison joined #rest |
| 01:55 |
|
|
ramsey joined #rest |
| 01:58 |
|
|
tr3online joined #rest |
| 02:04 |
|
|
shrink0r_ joined #rest |
| 02:16 |
|
|
shrink0r joined #rest |
| 02:22 |
|
|
lemur joined #rest |
| 02:32 |
|
|
shrink0r_ joined #rest |
| 02:42 |
|
|
shrink0r joined #rest |
| 02:59 |
|
|
lemur joined #rest |
| 03:07 |
|
|
shrink0r_ joined #rest |
| 03:19 |
|
|
shrink0r joined #rest |
| 03:21 |
|
|
shrink0r_ joined #rest |
| 03:37 |
|
|
shrink0r joined #rest |
| 03:50 |
|
|
shrink0r_ joined #rest |
| 03:59 |
|
|
shrink0r joined #rest |
| 07:07 |
|
|
shrink0r joined #rest |
| 07:15 |
|
|
_ollie joined #rest |
| 07:51 |
|
|
lemur joined #rest |
| 08:33 |
|
|
rosstuck joined #rest |
| 08:55 |
|
|
shrink0r joined #rest |
| 08:59 |
|
|
graste joined #rest |
| 10:18 |
|
|
martinfilliau joined #rest |
| 10:48 |
|
|
Left_Turn joined #rest |
| 10:49 |
|
|
shrink0r joined #rest |
| 10:50 |
|
|
shrink0r joined #rest |
| 11:02 |
|
|
benaiah joined #rest |
| 11:02 |
|
|
dreamdust joined #rest |
| 11:04 |
|
|
jgornick joined #rest |
| 12:34 |
|
|
mezod joined #rest |
| 12:42 |
|
|
zama joined #rest |
| 13:41 |
|
|
shrink0r joined #rest |
| 14:39 |
|
|
ralphschindler joined #rest |
| 14:49 |
|
|
nkoza joined #rest |
| 15:22 |
|
|
shrink0r joined #rest |
| 15:23 |
|
|
saml joined #rest |
| 15:31 |
|
|
shrink0r joined #rest |
| 16:07 |
|
|
graste joined #rest |
| 16:32 |
|
|
fumanchu joined #rest |
| 18:48 |
|
|
proteusguy joined #rest |
| 19:09 |
|
|
Judasbricot joined #rest |
| 19:10 |
|
|
Judasbricot joined #rest |
| 19:10 |
|
|
mikehaas763 joined #rest |
| 19:13 |
|
mikehaas763 |
Is there anything in REST and/or HATEOAS that says a resource cannot have a property that is a dynamic nested object ? |
| 19:14 |
|
_ollie |
resources neither have properties not "dynamic nested objects" :) |
| 19:14 |
|
_ollie |
they have representations |
| 19:15 |
|
Judasbricot |
and HATEOAS is one of the criteria of REST. |
| 19:16 |
|
mikehaas763 |
I know this lol, I guess I shouldn't expect anything but the utmost purity in a channel dedicated to REST :) |
| 19:16 |
|
_ollie |
:) |
| 19:17 |
|
mikehaas763 |
I'm just struggling with a design from a pragmatic view at this point |
| 19:17 |
|
_ollie |
what I wanted to say is: what your representation consists of is purely up to you, it should represent the state of the resource though |
| 19:19 |
|
Judasbricot |
and hopefully, this representation can either be static or dynamic |
| 19:19 |
|
asdf` |
mikehaas763, hmm, what do you mean 'dynamic nested object'? |
| 19:19 |
|
mikehaas763 |
Can you help me understand that a bit better. So let's say I have a JSON representation... what is an example of it needing to represent the state of the resource? |
| 19:19 |
|
_ollie |
the JSON representation… |
| 19:20 |
|
_ollie |
I'm unsure of what you're referring to as dynamic nested object… |
| 19:20 |
|
_ollie |
especially the "dynamic" part of it… does it mean, that it changes quite often? |
| 19:21 |
|
mikehaas763 |
asdf`, I mean, a consumer of the api could send in an arbitrary object like { foo: { bar: "baz" } | |
| 19:21 |
|
_ollie |
REST isn't a good fit for very frequently changing data (sub second times) as the protocol overhead usually becomes quite significant then |
| 19:21 |
|
asdf` |
i'm not quite sure how would that be really different than having the consumer send eg. an arbitrary string :) |
| 19:22 |
|
_ollie |
if you want to send JSON you send JSON… |
| 19:23 |
|
mikehaas763 |
Ok, I'm thinking I'm maybe just struggling getting my brain from internal application code to REST design |
| 19:23 |
|
Judasbricot |
what do you mean _ollie by "very frequently changing data" ? You mean "client requesting a modification/changement (whatever..) of a resource state " ? |
| 19:24 |
|
whartung |
he's talking about HTTP resource tend to be coarse simply due to the high overhead of the protocol |
| 19:25 |
|
_ollie |
No if you have a resource whose state is changing very frequently (e.g. stock price) and the client needing to be up to date e.g. every 10 seconds then a REST approach might create too much overhead |
| 19:25 |
|
_ollie |
that "no" was for Judasbricot :) |
| 19:26 |
|
_ollie |
you don't want to GET a new resource state every 2-3 seconds… the longer it can live in a certain state, the better |
| 19:26 |
|
|
shrink0r joined #rest |
| 19:26 |
|
Judasbricot |
In my understanding of REST, it's more about the underlying protocol (well, CoAP could be suitable rather HTTP there) than the architectural style |
| 19:27 |
|
mikehaas763 |
I'm creating an internal web service that consumers can POST a payment representation to. They can post it to a number of different payment providers (eg paypal, stripe, etc). In some situations a specific provider may in turn accept custom data (could be just display purposes). So like I said I'm sure I'm just having a hard time getting away from the internal application specifics |
| 19:27 |
|
whartung |
wow that's pretty much completely the opposite. |
| 19:27 |
|
whartung |
RESTis an architecture. HTTP is a protocol |
| 19:28 |
|
Judasbricot |
that's what i said. |
| 19:28 |
|
whartung |
funny, the order seemed different to me Judasbricot |
| 19:33 |
|
Judasbricot |
:-) no, i was not agree with the "REST isn't a good fit for very frequently changing data" which rely, for me, to a protocol issue (http and it's request/response design) rather than the architectural style itself |
| 19:34 |
|
_ollie |
Judasbricot: interesting… |
| 19:34 |
|
whartung |
that's fair |
| 19:34 |
|
mikehaas763 |
I'll ask a more direct question to see if I can wrap my head around some of this. If I have the resources /providers/heartland/payments and /providers/paypal/payments it it implied by REST constrains that a JSON representation of both resources need to be the same data structure? |
| 19:34 |
|
mikehaas763 |
s/it it/is it |
| 19:34 |
|
_ollie |
although I'd argue that basically derives from the statelessness requirement as it imposes (re)connection overhead on a request |
| 19:34 |
|
whartung |
to a point, even Fielding leans towards coarse transactions, but that may be influenced by http |
| 19:35 |
|
_ollie |
again, I'd argue that's implicitly based on the statelessness constraint |
| 19:36 |
|
_ollie |
basically a consequence of one of the design constraints |
| 19:36 |
|
whartung |
certainly. but they're you're talking connection overhead, which is above and beyond protocol overhead |
| 19:37 |
|
_ollie |
so let me replace "connection overhead" (applied rest) with "communication overhead required to fulfil the statelessness constraint" (pure rest) |
| 19:39 |
|
whartung |
there's a general point, it's certainly not designed for the very high transaction rates, partially due to the stateless nature. |
| 19:39 |
|
whartung |
but given that |
| 19:40 |
|
whartung |
you can have a stateful conneiton (it works fine over SSL for example, and much of HTTP is/can be pipelined today) that is SEMANTICALLY stateles (each request is stateles to the application, but not the underlying carrier). |
| 19:50 |
|
Judasbricot |
hmm not sure to understand correctly what you wrote whartung :D |
| 19:51 |
|
Judasbricot |
you means that the protocol itself can be stateful but the server itself don't store any information about client ? |
| 19:51 |
|
whartung |
the stateless constraint in rest is APPLICATION state. Not necessarily the underlying protocol state. The most blatant example is simply TCP -- TCP is not a stateless protocol. |
| 19:51 |
|
whartung |
yea |
| 19:52 |
|
Judasbricot |
ok, i agree :) ! |
| 19:53 |
|
_ollie |
good point |
| 19:53 |
|
mikehaas763 |
Do the resources of a collection all have to have the same representation? |
| 19:54 |
|
mikehaas763 |
* sorry, I meant the same representation data structure? |
| 19:55 |
|
Judasbricot |
hmm I guess no. You are duplicating your resource. What is the benefit between a resource /a/b and /x/y that return you the same representation ? Better to have single one imo |
| 19:57 |
|
Judasbricot |
But as explained by R. Fielding, sometimes a same representation can be return for two distinct resource. Typical example is: a resource "/my_software/version/1.0" and "/my_software/currentRelease" that can returns the same representation if the current release is related to the version 1.0 |
| 19:58 |
|
Judasbricot |
(his example is at chapter "5.2.1.1 Resources and Resource Identifiers" btw) |
| 20:06 |
|
|
tr3online joined #rest |
| 20:42 |
|
mikehaas763 |
Judasbricot, thanks for the example |
| 20:43 |
|
mikehaas763 |
I think I've figured out that because I use serialization my ResourceModels projects is really essentially my representations |
| 20:44 |
|
mikehaas763 |
ResourceModels is C# OO classes |
| 20:44 |
|
Judasbricot |
so ResourceModels is your representation serve by a resource ? |
| 20:45 |
|
Judasbricot |
(serialized in whatever format you want, json, xml, ...) |
| 20:47 |
|
mikehaas763 |
Judasbricot, if I understand you correctly, yes |
| 20:50 |
|
Judasbricot |
yep, why not. For example a resource representation of the resource "Profil" (of facebook) could be a class ProfileModel with some attributes such as firstName, lastName, age, etc. |
| 20:51 |
|
Judasbricot |
You are free to choose the resource representation that you want (here its ProfileModel but it could an other class with different attributs). It depends of the purpose of your REST API |
| 20:54 |
|
Judasbricot |
I think the drawback of REST is that, initially, it's looks like simple. But is much harder to understand in reality. |
| 20:59 |
|
mikehaas763 |
I see. Whereas previously would've thought of ProfileModel as my resource. It sounds like resources are really a much more abstract idea. |
| 21:01 |
|
Judasbricot |
resources are (usually, but not exclusively) nouns. But the notion of a resource call Profil for Facebook is different of the notion of Profil in Linkedin (or Google+). |
| 21:02 |
|
Judasbricot |
that's just an "idea" as you said |
| 21:22 |
|
|
ralphschindler joined #rest |
| 21:44 |
|
|
talios joined #rest |
| 22:23 |
|
|
dreamdust joined #rest |
| 23:24 |
|
|
locks joined #rest |
| 23:38 |
|
StatelessCat |
Judasbricot: "Judasbricot | resources are (usually, but not exclusively) nouns. But the notion of a resource call Profil for Facebook is different of the notion of Profil in Linkedin (or Google+)." --> That's why onlogies exists, no ? |
| 23:38 |
|
StatelessCat |
to remove the ambiguiyty of what is a Web Ressource |
| 23:38 |
|
StatelessCat |
to add some context to a ressource |
| 23:40 |
|
Judasbricot |
you cannot agreed on the notion of a resource. Because you design your resource following your requirement and your need |
| 23:41 |
|
Judasbricot |
But you can agree about the content of your resource (representation of your resource) that is related to a common and shared vocabulary that is ontology |
| 23:42 |
|
StatelessCat |
ok i understand what you mean, it's interesting |
| 23:44 |
|
dreamdust |
And at removing such ambiguity ontologies are a total failure |
| 23:44 |
|
dreamdust |
and unnecessary |
| 23:47 |
|
Judasbricot |
i hope there are not |
| 23:48 |
|
Judasbricot |
http://answers.semanticweb.com/questions/2918/why-is-rdf-so-old-complicated-unpopular-and-still-not-discarded : the website is broken (502 error) but when it will be no longer, go take a look dreamdust |
| 23:49 |
|
Judasbricot |
(btw, answers semantic has a lot of problem..) |
| 23:52 |
|
|
ChrisAnn joined #rest |
