Time |
S |
Nick |
Message |
00:01 |
|
|
fumanchu_ joined #rest |
00:18 |
|
|
fumanchu joined #rest |
00:40 |
|
|
fumanchu joined #rest |
02:13 |
|
|
fumanchu_ joined #rest |
03:03 |
|
|
baweaver joined #rest |
03:11 |
|
|
talios joined #rest |
04:35 |
|
|
mgomezch joined #rest |
05:43 |
|
|
fumanchu joined #rest |
06:18 |
|
|
_ollie joined #rest |
06:38 |
|
|
timg___ joined #rest |
07:23 |
|
|
interop_madness joined #rest |
08:06 |
|
|
graste joined #rest |
08:14 |
|
|
chthon joined #rest |
08:16 |
|
|
rosstuck joined #rest |
08:17 |
|
|
baweaver joined #rest |
08:21 |
|
|
fumanchu_ joined #rest |
11:00 |
|
|
chthon joined #rest |
11:43 |
|
|
timg___ joined #rest |
11:43 |
|
|
timg___ joined #rest |
12:04 |
|
|
timg___ joined #rest |
12:16 |
|
|
rickharrison joined #rest |
13:46 |
|
|
KotoRez joined #rest |
13:49 |
|
KotoRez |
I am trying to migrate trac to youtrack and when I run the mgration script it fails at creating custom fields with an error " Youtrack.YouTrackException /admin/customfield/bundle/BundleName/? 405 Method No Allowed". Does anyone know the common causes of this error? |
13:50 |
|
pdurbin |
No Allowed? |
13:55 |
|
|
_ollie joined #rest |
13:56 |
|
|
b0w7i3 joined #rest |
14:04 |
|
KotoRez |
Not* |
14:05 |
|
pdurbin |
KotoRez: maybe try PUT instead of POST or whatever |
14:07 |
|
b0w7i3 |
Hey, i have a resource A the creation of which involves references to two other resources B and C, plus some configuration for each. The problem I've got is that the exact configuration properties necessary are specific to each of the individual component resources. That is, the parameters that need to be filled in when I create an A with a B are contained within the representation of B. It seems that my options are 1) to have A construction take an arbitrary b |
14:07 |
|
b0w7i3 |
Are those really my only two options, and if so, which is the better one? Thanks. |
14:10 |
|
fumanchu_ |
b0w7i3: your first message got cut off after "1) to have A construction take an arbitrary bl" |
14:11 |
|
pdurbin |
cut off arbitrarily |
14:11 |
|
fumanchu_ |
(frickin slack babies think bits are infinite ;) |
14:11 |
|
b0w7i3 |
1) to have A construction take an arbitrary blob of parameters, or 2) to create new resources that are essentially "B with configuration", "C with configuration", etc, and let A expect any of those. |
14:11 |
|
b0w7i3 |
Are those really my only two options, and if so, which is the better one? Thanks. |
14:12 |
|
b0w7i3 |
fumanchu_: (Indeed. What's with your bits… they stop too soon.) |
14:12 |
|
fumanchu_ |
:) |
14:13 |
|
KotoRez |
it wants PUT but gives 405. Looks like I have to teak the youtrack server to accept PUT. I wish I knew where to configure that |
14:15 |
|
fumanchu_ |
b0w7i3: (1) seems easier to develop. (2) seems more powerful/maintainable. depends on which is more valuable to you at this time... |
14:16 |
|
fumanchu_ |
it's a very nice thing when your media type allows you to send (a representation of) an A and a B in the same message |
14:17 |
|
fumanchu_ |
one big determinant is how much B and C depend on A. Can they exist without an A? |
14:18 |
|
|
timg___ joined #rest |
14:18 |
|
b0w7i3 |
yes, they do exist apart from A |
14:18 |
|
b0w7i3 |
and A is just a pair of them with some extra wiring |
14:19 |
|
fumanchu_ |
I would tend to make two calls then. Make a couple of Bs or Cs and then include their URIs when you make a separate call to form A |
14:20 |
|
b0w7i3 |
yeah, it's just the extra wiring (the configuration) that's a problem |
14:20 |
|
fumanchu_ |
oic |
14:21 |
|
b0w7i3 |
each B and C are allowed to have arbitrary key/value pairs in there that represent user-configuration of B or C. So when a user is making an A, they grab their B, fill in its particular parameters, grab a C and do the same, and then combine them and submit a new A using B and C and their two sets of parameters |
14:21 |
|
b0w7i3 |
when you create a B, you specify the parameters (the key/value pairs) |
14:22 |
|
b0w7i3 |
that will need to be filled in later |
14:22 |
|
fumanchu_ |
so when you submit a new A you're essentially altering B and C as well? or making new instances from them as if they were templates? |
14:23 |
|
b0w7i3 |
you're not altering B and C, but you're filling in the template for B and for C |
14:24 |
|
b0w7i3 |
B and C are complete in themselves, and what they represent is essentially a template for creating half of an A |
14:24 |
|
fumanchu_ |
I see |
14:24 |
|
fumanchu_ |
then (2) looks more and more attractive |
14:25 |
|
b0w7i3 |
(2) confuses me because i don't want to have a separate resource on the server that is "B with filled-in-template", because that's what A was supposed to be (except that A *also* contains the fact that we're connecting a particular B with a particular C) |
14:25 |
|
fumanchu_ |
especially if you start allowing default values for the filled-out B and C. they might not even be different types, just "more filled out". |
14:25 |
|
fumanchu_ |
think prototyal inheritance, not class hierarchy |
14:25 |
|
b0w7i3 |
but maybe that's what i should do… the problem is that i'll never configure, for example, B without also creating an A for it to go in |
14:25 |
|
fumanchu_ |
prototypal |
14:26 |
|
b0w7i3 |
so it seems natural for A to contain that information |
14:31 |
|
fumanchu_ |
I think you're still going to want A.B and A.C to be separate nestings, not a flat blob of params |
14:31 |
|
fumanchu_ |
you could have A.B.prototype = /path/to/B/{prototypeid}/ and A.C.prototype = /path/to/C/{prototypeid}/ to maintain the link |
14:32 |
|
fumanchu_ |
just because there is an *object* B contained in the representation of A does not mean you have a separate *resource* B |
14:32 |
|
b0w7i3 |
i'm not sure i'm following |
14:33 |
|
b0w7i3 |
B is a separate resource. users can create them |
14:35 |
|
b0w7i3 |
would it be bad if every time a resource X (of the ilk of B and C) is created, i also call into existance a new "X-config" *type* of resource to go with it? and then when you go to create an A, you first actually create an X-config (which is to say, you fill in the parameters), and then you reference it in your new A? |
14:37 |
|
b0w7i3 |
(as an aside, is type the right word? Is a "resource" the collection of things for which you're getting representations, like "shoes", or is a resource the thing itself for which you're getting a representation?) |
14:37 |
|
fumanchu_ |
objects are not resources. Every resource is identifiable by a URI. if GET /path/to/all_A/{id}/ returns {body: {B: {x: 1, proto: /path/to/B_templates/{id}/}}} then body['B'] is not a resource (it has no URI), it is an object. body['B']['proto'] is a reference to a resource, and when you GET it its representation will probably contain one or more objects. |
14:39 |
|
fumanchu_ |
your media type can certainly define body['B'] and an object you GET from /path/to/B_templates/{id}/ to have the same representation "type", even if the latter "is a resource" and the former isn't |
14:40 |
|
b0w7i3 |
my media type for A or my media type for B? (this is good stuff, thank you) |
14:40 |
|
fumanchu_ |
don't they have the same media type? |
14:40 |
|
fumanchu_ |
(this is why they should) |
14:42 |
|
fumanchu_ |
in mine for example (Shoji: https://bitbucket.org/fumanchu/shoji/src/tip/spec.txt?at=default#spec.txt-24) there is one media type "shoji" but multiple object types (catalog, entity, view, order) |
14:42 |
|
b0w7i3 |
i think i've been laboring under a misconception about media types… i expected there to be a separate media type for As and (B and C)s |
14:43 |
|
fumanchu_ |
yes. if you make a separate media type for each thing we programmers would probably call an OO "class" then you have to do crazy things like multipart MIME to combine them |
14:44 |
|
fumanchu_ |
"media type" is more like "programming language" than "OO class" |
14:44 |
|
fumanchu_ |
(but all declarative in a REST world) |
14:44 |
|
fumanchu_ |
(mostly) |
14:45 |
|
b0w7i3 |
thanks fumanchu_. I'm going to chew on your suggestions for a minute. i need to absorb this latest revelation |
14:46 |
|
fumanchu_ |
my pleasure. good luck :) |
14:54 |
|
b0w7i3 |
so the representation for B_proto would contain a reference to x and it's type (integer), and the media type would describe the purpose of such references to be a template for creating a B object |
14:54 |
|
b0w7i3 |
B_proto is a resource, but B is just an object described by the media type |
14:55 |
|
b0w7i3 |
A "expects" (a function of the media type) a B object during it's creation |
14:56 |
|
b0w7i3 |
fumanchu_: does that sound right? |
15:03 |
|
|
timg___ joined #rest |
15:11 |
|
|
saml joined #rest |
15:12 |
|
b0w7i3 |
fumanchu_: gotta head out, but thank you again for your help. |
15:14 |
|
fumanchu_ |
yes! (too late) |
15:16 |
|
fumanchu_ |
the media type itself doesn't need to describe that *purpose* (that's up to the application using the media type) but it can describe that B.prototype is a URI which references a prototypal B (and even define rules for inheriting or merging B with B.prototype) |
15:58 |
|
KotoRez |
has anyone worked with Youtrack's REST api? |
16:20 |
|
|
sfisque joined #rest |
16:36 |
|
|
ralphschindler joined #rest |
17:32 |
|
|
azer_ joined #rest |
17:48 |
|
|
timg___ joined #rest |
17:50 |
|
|
timg___ joined #rest |
18:27 |
|
|
timg___ joined #rest |
18:30 |
|
|
timg____ joined #rest |
18:31 |
|
|
timg_____ joined #rest |
18:59 |
|
|
adaro joined #rest |
19:22 |
|
|
b0w7i3 joined #rest |
19:24 |
|
b0w7i3 |
fumanchu_: thanks. :) I looked up your response in the logs |
19:25 |
|
|
upasana joined #rest |
19:57 |
|
pdurbin |
logs++ |
20:38 |
|
|
Coldblackice joined #rest |
22:09 |
|
|
fuzzyhorns joined #rest |
23:18 |
|
|
jatb joined #rest |
23:19 |
|
|
b0w7i3 joined #rest |
23:28 |
|
|
adaro joined #rest |
23:45 |
|
|
fuzzyhorns joined #rest |