| Time |
S |
Nick |
Message |
| 00:32 |
|
|
Klebel joined #rest |
| 02:07 |
|
|
PalyaPix joined #rest |
| 02:29 |
|
PalyaPix |
a |
| 02:31 |
|
PalyaPix |
s |
| 03:25 |
|
|
scflode_ joined #rest |
| 04:49 |
|
|
dar_ joined #rest |
| 04:51 |
|
dar_ |
Anyone , how to make rest api if i have more than one role ? |
| 04:52 |
|
dar_ |
If i want display all schedule /api/schedule |
| 04:52 |
|
|
PalyaPix joined #rest |
| 04:54 |
|
dar_ |
If i want display user schedule /api/user/{userId}/schedule |
| 04:56 |
|
dar_ |
How to display schedule by role? |
| 05:16 |
|
dreamdust |
dar_: /api/user/:id/schedule?role=winner |
| 05:16 |
|
dreamdust |
(boom) |
| 05:17 |
|
dar_ |
Is it good using query for role? |
| 06:40 |
|
|
PalyaPix joined #rest |
| 07:12 |
|
|
PalyaPix joined #rest |
| 08:08 |
|
|
marcoslamuria joined #rest |
| 09:27 |
|
|
interop_madness joined #rest |
| 10:32 |
|
|
mezod joined #rest |
| 10:47 |
|
|
Left_Turn joined #rest |
| 11:33 |
|
|
graste joined #rest |
| 12:22 |
|
interop_madness |
is it common to adhere to the difference between PUT (RFC2616) and PATCH (RFC5789) for REST services? reading RFC2616, i don't find it spelled out that PUT flat out *replaces* the target resource with the enclosed entity, as RFC5987 asserts. |
| 12:23 |
|
interop_madness |
quote RFC2616: "If the Request-URI refers to an already |
| 12:23 |
|
interop_madness |
existing resource, the enclosed entity SHOULD be considered as a |
| 12:23 |
|
interop_madness |
modified version of the one residing on the origin server.". that could mean anything, it does not necessarily imply replacing the resource altogether. |
| 12:26 |
|
|
jgornick joined #rest |
| 12:26 |
|
|
igitoor joined #rest |
| 12:26 |
|
|
blindscreen joined #rest |
| 12:26 |
|
|
gluegadget joined #rest |
| 12:26 |
|
|
ChrisAnn joined #rest |
| 12:26 |
|
trygvis |
http://tools.ietf.org/html/rfc7231#section-4.3.4 |
| 12:26 |
|
|
rincewind_ joined #rest |
| 12:26 |
|
|
Davey joined #rest |
| 12:26 |
|
|
fumanchu joined #rest |
| 12:26 |
|
|
pdurbin joined #rest |
| 12:26 |
|
|
daxim joined #rest |
| 12:27 |
|
|
blahdeblah joined #rest |
| 12:27 |
|
|
jgornick joined #rest |
| 12:27 |
|
trygvis |
PUT has been abused for PATCH for a long time, but it's no reason to stop old bad behaviour |
| 12:28 |
|
|
dreamdust joined #rest |
| 12:32 |
|
interop_madness |
what pisses me off is that PATCH implies a "set of instructions" for modification. it seems complicated for a consumer of an RFC5789-compliant webservice to do partial updates |
| 12:39 |
|
trygvis |
why is that bad? |
| 12:39 |
|
trygvis |
it's entirely up to the hypermedia you're sending |
| 12:40 |
|
interop_madness |
i would be OK with it, but a third party developer without client library might see it as overly complicated |
| 12:41 |
|
interop_madness |
but it gets more clear that there probably needs to be an up-to-date reference client implementation for the REST service to alleviate these problems |
| 12:43 |
|
Jarda |
waiting for a decent json-diff -library |
| 12:43 |
|
Jarda |
or a format even |
| 12:46 |
|
interop_madness |
Jarda, RFC6902? |
| 12:46 |
|
Jarda |
I don't like the syntax but yeah |
| 12:47 |
|
Jarda |
tooling just is lagging |
| 12:47 |
|
Jarda |
I can't expect my API consumers to use such format |
| 12:47 |
|
interop_madness |
that's my problem exactly (only for custom XML-derived formats) |
| 12:47 |
|
Jarda |
so I'm just abusing PUT |
| 12:48 |
|
Jarda |
all keys missing from the request body are left intact |
| 12:48 |
|
Jarda |
so you can do PUT {"name": "Something new"} |
| 12:48 |
|
Jarda |
and all other properties are unchanged |
| 12:48 |
|
interop_madness |
at some later point, i will differentiate between PUT and PATCH and require PUT entities to be complete. at that point i can require those who think the media types for PATCH are too complicated, to use PUT instead |
| 12:49 |
|
interop_madness |
yes, Jarda i'm currently doing the same (for some of the resource types) |
| 12:49 |
|
interop_madness |
some are PUT /some/file, which i hope nobody will ever try to use partially |
| 12:52 |
|
Jarda |
but tooling for RFC6902 is catching up |
| 12:52 |
|
Jarda |
so maybe some day.. |
| 12:59 |
|
trygvis |
for stuff that's really service endpoints (like 'send invoice') we post custom documents (i.e. service specific) (usually including URLs to other resources) |
| 12:59 |
|
trygvis |
for the rest we just require full representations |
| 12:59 |
|
trygvis |
versioning and stuff becomes a hassle with patches |
| 13:48 |
|
|
Andre-B joined #rest |
| 13:53 |
|
|
nkoza joined #rest |
| 15:27 |
|
fumanchu |
Jarda: I did something very similar for Shoji, which, because it is *not* a completely unstructured JSON doc, can supply meaningful constraints on what that PATCH format looks like: https://bitbucket.org/fumanchu/shoji/src/984733415cf8e9029f9dfd32fb14eccd30a8897b/spec.txt?at=default#cl-800 |
| 15:28 |
|
fumanchu |
without having to invent a separate grammar to describe edits to JSON |
| 15:49 |
|
|
rincewind_ joined #rest |
| 15:53 |
|
|
marcoslamuria joined #rest |
| 16:04 |
|
|
marcoslamuria joined #rest |
| 16:08 |
|
|
begriffs joined #rest |
| 16:32 |
|
|
begriffs joined #rest |
| 16:55 |
|
|
fsvehla joined #rest |
| 17:08 |
|
|
begriffs joined #rest |
| 17:34 |
|
|
begriffs joined #rest |
| 17:57 |
|
|
adaro joined #rest |
| 17:57 |
|
|
dar_ joined #rest |
| 18:07 |
|
|
begriffs joined #rest |
| 18:24 |
|
|
begriffs joined #rest |
| 18:24 |
|
|
ralphschindler joined #rest |
| 18:38 |
|
|
begriffs joined #rest |
| 19:27 |
|
|
begriffs joined #rest |
| 19:34 |
|
|
begriffs joined #rest |
| 20:21 |
|
|
begriffs joined #rest |
| 20:45 |
|
|
begriffs joined #rest |
| 20:53 |
|
|
begriffs joined #rest |
| 21:16 |
|
|
begriffs joined #rest |
| 22:42 |
|
|
proteusguy joined #rest |
| 22:42 |
|
|
marcoslamuria joined #rest |
| 23:11 |
|
|
adaro joined #rest |
