Time |
S |
Nick |
Message |
00:00 |
|
|
ralphschindler joined #rest |
00:30 |
|
|
HighBit joined #rest |
01:48 |
|
|
pgicxplzs joined #rest |
02:06 |
|
|
warehouse13 joined #rest |
02:27 |
|
|
mezod joined #rest |
03:14 |
|
|
pgicxplzs joined #rest |
03:31 |
|
|
blindscreen_ joined #rest |
03:35 |
|
|
ralphschindler joined #rest |
03:54 |
|
|
ralphschindler joined #rest |
03:54 |
|
|
Angry_Roy_Fieldi joined #rest |
05:03 |
|
|
whatacold joined #rest |
05:21 |
|
|
proteusguy joined #rest |
05:25 |
|
|
proteusguy joined #rest |
05:29 |
|
|
proteusguy joined #rest |
05:35 |
|
|
proteusguy joined #rest |
05:39 |
|
|
proteusguy joined #rest |
05:55 |
|
|
ralphschindler joined #rest |
06:00 |
|
|
proteusguy joined #rest |
06:10 |
|
|
blahdeblah joined #rest |
06:10 |
|
|
blahdeblah joined #rest |
06:14 |
|
|
lemur joined #rest |
06:20 |
|
|
blahdeblah_ joined #rest |
07:34 |
|
|
proteusguy joined #rest |
07:44 |
|
|
blahdeblah joined #rest |
07:48 |
|
|
blahdeblah_ joined #rest |
09:51 |
|
|
lemur joined #rest |
09:59 |
|
|
quimrstorres joined #rest |
10:04 |
|
|
quimrstorres joined #rest |
10:08 |
|
|
quimrstorres joined #rest |
10:24 |
|
|
quimrstorres joined #rest |
10:39 |
|
|
quimrstorres joined #rest |
10:46 |
|
|
Left_Turn joined #rest |
11:01 |
|
|
quimrsto_ joined #rest |
11:58 |
|
|
_ollie joined #rest |
12:29 |
|
|
_ollie1 joined #rest |
12:40 |
|
|
adaro joined #rest |
12:56 |
|
|
mezod joined #rest |
13:51 |
|
|
shrink0r joined #rest |
14:25 |
|
|
_ollie joined #rest |
14:34 |
|
|
wsiqueir joined #rest |
14:45 |
|
|
vlakarados joined #rest |
14:45 |
|
|
zama joined #rest |
14:55 |
|
|
shrink0r_ joined #rest |
15:17 |
|
|
Judasbricot joined #rest |
15:18 |
|
|
shrink0r joined #rest |
15:45 |
|
|
shrink0r_ joined #rest |
16:19 |
|
|
DrCode joined #rest |
16:39 |
|
Judasbricot |
Hmmm i'm stuck on a problem when designing my REST API. I have a resource "payment" on which a user can make a POST to make the payment. When making a POST on it, it will start an asynchronous operation, thus resulting with the creation of a /payment/queue/"id" resource for monitoring the status of it |
16:40 |
|
Judasbricot |
my question is the following, since the created resource is /payment/queue/"id". Does the make operation as to be on /payment/queue or /payment ? I read that POST is suitable for creating subordinate resource (while /payment and /payment/queue/id are sub-subordinate :-) !) |
16:40 |
|
Judasbricot |
the POST operation*. |
16:52 |
|
asdf` |
Judasbricot, just having an additional .../queue in the url doesn't mean there's a separate conceptual resource; there's nothing wrong if /payment/queue/1 is a child of /payment/42 |
16:53 |
|
asdf` |
Judasbricot, you could even make it so the payment url is /1a2b3c4d and POSTing to it creates a child resource at /a1b2c3d4, would be the same thing as far as REST is concerned |
16:54 |
|
asdf` |
Judasbricot, (important thing is, issuing a GET at /payments/1 returns a representation that tells you there's a child resource at /payments/queue/42, ie. there's a link somewhere there) |
17:05 |
|
Judasbricot |
thanks asdf`. In my understanding, you mean that the URL does not necessarly refer to a meaning, right ? |
17:05 |
|
Judasbricot |
a meaning, a concept, whatever.. :) |
17:06 |
|
trygvis |
an URL is to be treated as opaque |
17:07 |
|
trygvis |
and a POST can do whatever it want |
17:12 |
|
Judasbricot |
About the opaque URI, even R. Fielding is a little "opaque" about it :-) ! See: https://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/3232 where he wrote "REST does not require that a URI be opaque" |
17:14 |
|
Judasbricot |
I guess, it could be a debate. I've read http://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-hackable-urls/ where this guys encourages to use non-hackable urls (= opaque) |
19:30 |
|
|
shrink0r joined #rest |
19:38 |
|
|
lemur joined #rest |
20:14 |
|
|
begriffs joined #rest |
20:45 |
|
|
begriffs_ joined #rest |
20:53 |
|
|
_ollie joined #rest |
21:00 |
|
Judasbricot |
A question: how a client using my REST API can know what parameter to put in its body when he request a POST on a resource ? Does it rely enterily on a out-band knowledge or on the MIME type that can give hint about it ? |
21:02 |
|
pdurbin |
what are the possible parameters? |
21:05 |
|
Judasbricot |
just a string. |
21:06 |
|
Judasbricot |
If it's possible i would like to tell some String value that he can choose and POST it on a resource :) |
21:06 |
|
Judasbricot |
provide* |
21:07 |
|
pdurbin |
could he do a GET to see the String values that are supported? |
21:10 |
|
Judasbricot |
Well. Imagine a ressource "A1" that is the entry point, where client performs a GET on it, and returns some informations + a link to a ressource "A2" where he can perform a POST. I would like to know how the client can know what he has to fill in the body of its "POST A2" request |
21:11 |
|
Judasbricot |
does the response of the "GET A1" can contains hints for filling this body ? |
21:13 |
|
trygvis |
Judasbricot: if you want to follow REST, you shouldn't rely on any out of band info |
21:14 |
|
pdurbin |
I have a similar need. We have a "controlled vocabulary" for "subject" (a required field) when creating a dataset via POST. Possible values for "subject" are "Chemistry", "Engineering", "Physics", etc. Not sure how best to communicate these to a client. |
21:15 |
|
Judasbricot |
exactly :-) ! |
21:17 |
|
Judasbricot |
that's why trygvis, i guess its the MIME type that can provide this information. Because both side (server/client) agreed on it (i assume you got a 2xx response here) and is intended to self-describe the meaning of a request/response. |
21:18 |
|
|
lemur joined #rest |
21:19 |
|
pdurbin |
right now this is what we return: {"status":"ERROR","message":"Error parsing datasetVersion: Value 'junk' does not exist in type 'subject'"} |
21:19 |
|
pdurbin |
would be nice to return the possible values, I guess |
21:20 |
|
pdurbin |
any suggestions are welcome :) |
21:20 |
|
Judasbricot |
the status should depends of the response code of the protocol (http i guess in your case). No ? |
21:22 |
|
|
DrCode joined #rest |
21:23 |
|
trygvis |
pdurbin: usually you would include the options as a part of what the agent requested in the first place |
21:23 |
|
trygvis |
so the agent start with GET /myresource, look at the possible operations and required parameters and does its POST |
21:24 |
|
Judasbricot |
trygvis, the main issue is how it know these parameters ? |
21:24 |
|
pdurbin |
trygvis: sounds like a good approach. Do you know of any APIs I could look at that work this way? |
21:25 |
|
trygvis |
pdurbin: HTML is probably the best example that actually does so |
21:25 |
|
trygvis |
I think also the siren stuff works in a similar fasion, but I haven't looked at it |
21:25 |
|
trygvis |
Judasbricot: well, you always need some knowledge |
21:26 |
|
trygvis |
like, in pdurbin's case, you know you have something called "subject", but you don't have to know it's possible values |
21:27 |
|
pdurbin |
siren stuff? |
21:27 |
|
* pdurbin |
googles |
21:28 |
|
Judasbricot |
Yup trygvis. But you introduce a coupling between client/server. Imagine you rename your field "subject" to "subjects" in the server |
21:28 |
|
Judasbricot |
your client will be broken |
21:29 |
|
pdurbin |
Structured Interface for Representing Entities - https://github.com/kevinswiber/siren |
21:31 |
|
pdurbin |
trygvis: I don't really see an example of communicating possible values via siren though. Communicating a controlled vocabulary I mean. |
21:33 |
|
trygvis |
Judasbricot: you can't break stuff. ever. |
21:34 |
|
trygvis |
so, either the media type tells you how to handle missing expected fields, or you die |
21:35 |
|
pdurbin |
I guess this is what I want: Input field that is an enumerated value · Issue #36 · kevinswiber/siren - https://github.com/kevinswiber/siren/issues/36 |
21:38 |
|
Judasbricot |
So the correct response is: none media type handle a set of "possible values" to help client for filling their body (put/post req.) :D |
21:38 |
|
trygvis |
HTML sure does |
21:39 |
|
trygvis |
I'm not sure if I would actually use html, but it does have it |
21:39 |
|
Judasbricot |
this one you mean ? application/x-www-form-urlencoded ? |
21:39 |
|
trygvis |
no <select><option>..</option></select> |
21:42 |
|
* pdurbin |
leaves a comment on that issue |
21:46 |
|
|
StatelessCat joined #rest |
22:01 |
|
Judasbricot |
hmmm i'm thinking about a possible solution for your problem pdurbin. Using POST with empty body and create as many resource as the number of your possible value of subject. The drawback imo, is thats looks like not really RESTful |
22:02 |
|
|
StatelessCat joined #rest |
22:02 |
|
* Judasbricot |
poke StatelessCat |
22:04 |
|
StatelessCat |
hey Judasbricot |
22:04 |
|
Judasbricot |
:-) |
22:07 |
|
StatelessCat |
Judasbricot += "pomme" |
22:07 |
|
StatelessCat |
apple* for english speakers |
22:08 |
|
Judasbricot |
apricot and apple juice... eurkk :p |
22:08 |
|
StatelessCat |
:) |
22:09 |
|
StatelessCat |
you can DELETE /Judasbricot/apple if you want to |
22:09 |
|
Judasbricot |
haha |
22:15 |
|
|
happyface joined #rest |
22:17 |
|
pdurbin |
Judasbricot: by "create as many resources" I assume you mean "return some JSON with an array of possible values" |
22:19 |
|
pdurbin |
probably it makes more sense to start with a GET like trygvis suggests. https://github.com/kevinswiber/siren/issues/36 talks a bit about how the representation is undefined in siren currently |
22:21 |
|
pdurbin |
Judasbricot: so we don't actually have the same problem? :) |
22:26 |
|
Judasbricot |
pdurbin, instead of returning a structure of { link: your_uri possible_value: { value1, value2, value3 } }, you return something like this: { link: { your_uri_value1, your_uri_value2, your_uri_value3} } |
22:27 |
|
Judasbricot |
and these uris (your_uri_value1, your_uri_value2, ...} are POST-ed with an empty body |
22:37 |
|
pdurbin |
hmm, well "subject" is one of many field that the user is expected to send in the JSON when doing a POST. To create a dataset the server is expecting JSON that looks something like this: https://github.com/IQSS/dataverse/blob/master/scripts/search/tests/data/dataset-finch1.json |
22:37 |
|
pdurbin |
fields* |
22:38 |
|
Judasbricot |
ok, forgot my idea then :D |
22:38 |
|
pdurbin |
in practice, for now, we'll probably just document what the possible values for "subject" are |
22:39 |
|
Judasbricot |
by documenting you mean with something like YAML or WADL ? |
22:40 |
|
pdurbin |
I'd like to use the http://swagger.io format (I think) but for now we're using .rst/sphinx: http://guides.dataverse.org/en/latest/api |
22:45 |
|
StatelessCat |
or Hydra :) |
22:48 |
|
pdurbin |
hmm. "Current APIs heavily rely on out-of-band information such as human-readable documentation" http://www.hydra-cg.com |
22:50 |
|
|
gluegadget_ joined #rest |
22:50 |
|
StatelessCat |
i'm missing something or in YAML you cannot specify a ressource as a "linked data" ? |
22:51 |
|
StatelessCat |
like "this ressource, that you can acess on /api/user with GET, POST, PUT, DELETE; is a schema.org/Person" |
22:51 |
|
StatelessCat |
you can do this with YAML / swagger? |
22:55 |
|
pdurbin |
not sure |
22:56 |
|
Judasbricot |
Hmm i was thinking about RAML (based on YAML). RAML allow to describe the structure of a response on a defined resource |
22:57 |
|
Judasbricot |
and also the supported methods on it |
22:57 |
|
Judasbricot |
http://raml.org/ |
22:59 |
|
pdurbin |
it's neat how with swagger you can actually execute the operations, the GETs etc. against a live server. seems like http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/api-demo/ is letting me do that too though |
23:02 |
|
StatelessCat |
yes, this video of Markus explain very well what Hydra can do https://www.youtube.com/watch?v=91wSt3fHWLE |
23:03 |
|
StatelessCat |
but Hydra is still a Draft spec, there are still arguing about what need to be or not in Hydra |
23:05 |
|
pdurbin |
ok |
23:20 |
|
|
lemur joined #rest |
23:26 |
|
Judasbricot |
interesting presentation StatelessCat :-) |
23:30 |
|
StatelessCat |
Judasbricot: yes Markus is an awesome genius :) |