| Time |
S |
Nick |
Message |
| 00:34 |
|
|
MLMitch joined #rest |
| 01:30 |
|
|
lemur joined #rest |
| 02:29 |
|
|
MLMitch joined #rest |
| 02:35 |
|
|
lemur joined #rest |
| 02:36 |
|
|
MLMitch joined #rest |
| 02:43 |
|
|
DrCode joined #rest |
| 02:57 |
|
|
mezod joined #rest |
| 03:48 |
|
|
MLMitch joined #rest |
| 03:54 |
|
|
tr3onlin_ joined #rest |
| 04:04 |
|
|
MLMitch joined #rest |
| 04:41 |
|
|
lemur joined #rest |
| 05:11 |
|
|
tr3online joined #rest |
| 05:16 |
|
|
tr3onlin_ joined #rest |
| 05:37 |
|
|
fumanchu joined #rest |
| 05:58 |
|
|
proteusguy joined #rest |
| 07:34 |
|
|
rosstuck joined #rest |
| 07:36 |
|
|
MLMitch joined #rest |
| 07:52 |
|
|
lemur joined #rest |
| 08:47 |
|
|
tr3online joined #rest |
| 09:16 |
|
|
graste joined #rest |
| 09:27 |
|
|
tr3online joined #rest |
| 09:29 |
|
|
tr3online joined #rest |
| 09:39 |
|
|
proteusguy joined #rest |
| 09:49 |
|
|
martinfilliau joined #rest |
| 10:07 |
|
|
marcoslamuria joined #rest |
| 10:35 |
|
|
proteusguy joined #rest |
| 11:15 |
|
|
tr3online joined #rest |
| 11:31 |
|
|
proteusguy joined #rest |
| 11:52 |
|
|
sulky joined #rest |
| 11:56 |
|
|
Left_Turn joined #rest |
| 12:31 |
|
|
sulky joined #rest |
| 12:33 |
|
|
BrunoC joined #rest |
| 12:40 |
|
|
Left_Turn joined #rest |
| 12:42 |
|
BrunoC |
hi all |
| 12:49 |
|
trygvis |
hello |
| 13:16 |
|
|
tr3online joined #rest |
| 13:48 |
|
|
nkoza joined #rest |
| 14:35 |
|
|
MLMitch joined #rest |
| 14:53 |
|
|
vlakarados joined #rest |
| 15:08 |
|
|
jackalista joined #rest |
| 15:18 |
|
|
tr3online joined #rest |
| 15:18 |
|
|
vlakarados_ joined #rest |
| 15:21 |
|
|
saml joined #rest |
| 15:46 |
|
BrunoC |
what do you think about json patch? (rfc6902) |
| 15:46 |
|
BrunoC |
Do you know any public API using it? |
| 15:48 |
|
trygvis |
nope |
| 15:48 |
|
trygvis |
I doubt there are many services that want to process changes in that kind of format |
| 15:49 |
|
trygvis |
adoption of the patch mentality will take along time if it ever catches on |
| 15:50 |
|
BrunoC |
Yes, I'm checking github api and they are using it as I'm at the moment for internal services |
| 15:50 |
|
BrunoC |
updating resources with partial JSON, instead of operations for the update |
| 15:51 |
|
BrunoC |
rfc6902 is ugly |
| 15:52 |
|
BrunoC |
but I found it flexible |
| 15:53 |
|
trygvis |
they are? hm |
| 15:54 |
|
trygvis |
where are they using it? |
| 15:54 |
|
trygvis |
I think the rfc6902 format itself is quite good, much better than the other proposed solutions at least |
| 16:16 |
|
saml |
how can i do transaction? multiple PUTs or POSTs should happen at once or none should happen |
| 16:16 |
|
trygvis |
you can't. it's a feature |
| 16:16 |
|
saml |
yah |
| 16:17 |
|
saml |
what if... POST /transaction gives new transaction id, /transaction/1 . and do POST /article/1?transaction=/transaction/1 .... etc |
| 16:18 |
|
saml |
and do POST /transaction/1 for commit |
| 16:18 |
|
saml |
clients can forget to commit. stale transactions can be cleaned up with DELETE /transaction/1 |
| 16:19 |
|
trygvis |
yep, that's the way to do it |
| 16:20 |
|
trygvis |
except that you should keep on modifying the same resource, not send stuff that should be a part of the body as query params |
| 16:20 |
|
trygvis |
but you know that :) |
| 16:20 |
|
saml |
ah right |
| 16:21 |
|
|
tr3online joined #rest |
| 16:21 |
|
trygvis |
wait, your POST is strange |
| 16:22 |
|
trygvis |
I'm not sure what you wanted to do there |
| 16:22 |
|
saml |
i want to update multiple articles. at once |
| 16:22 |
|
trygvis |
the core of the idea is to make the transaction a resource itself which you can operate on |
| 16:23 |
|
saml |
POST /articles?ids=1,2,3,4,5 |
| 16:48 |
|
BrunoC |
I would use POST, but instead of articles, I would use something like POST /articles/_bulk and have a resource such as {operation} {id} {document} |
| 16:48 |
|
BrunoC |
trygvis, github api:https://developer.github.com/v3/ |
| 16:48 |
|
BrunoC |
PATCHUsed for updating resources with partial JSON data. For instance, an Issue resource has title and body attributes. A PATCH request may accept one or more of the attributes to update the resource. PATCH is a relatively new and uncommon HTTP verb, so resource endpoints also accept POST requests. |
| 16:49 |
|
trygvis |
BrunoC: that's not rfc6209, that is the PATCH http verb |
| 16:49 |
|
BrunoC |
I know |
| 16:49 |
|
trygvis |
http://tools.ietf.org/html/rfc5789 |
| 16:49 |
|
BrunoC |
BrunoC> updating resources with partial JSON, instead of operations for the update |
| 16:50 |
|
trygvis |
I was confused by "they are using it" |
| 16:51 |
|
BrunoC |
I were saying that they use the same approach I'm using internally. |
| 16:51 |
|
BrunoC |
sorry |
| 16:51 |
|
BrunoC |
yeah |
| 16:52 |
|
trygvis |
in terms of REST the github stuff is mostly crap from what I've seen |
| 16:52 |
|
BrunoC |
Do you have any suggestion? |
| 16:53 |
|
BrunoC |
a better rest example |
| 17:08 |
|
|
jackalista joined #rest |
| 17:08 |
|
|
tr3online joined #rest |
| 17:10 |
|
fumanchu |
tooting my own horn, but I have yet to find a PATCH format better than |
| 17:11 |
|
fumanchu |
Shoji https://bitbucket.org/fumanchu/shoji/src/984733415cf8e9029f9dfd32fb14eccd30a8897b/spec.txt?at=default#cl-32 |
| 17:11 |
|
fumanchu |
(line 800ff) |
| 17:14 |
|
fumanchu |
every ad-hoc JSON PATCH implementation I've seen really wants the PATCH mime-type to be the same as GET/PUT |
| 17:14 |
|
fumanchu |
Shoji is the only one I've seen where that's actually true |
| 17:16 |
|
BrunoC |
RFC5789? |
| 17:18 |
|
BrunoC |
it's like github is using patch, right? |
| 17:18 |
|
fumanchu |
yes, very similar |
| 17:18 |
|
fumanchu |
only actually constrained by the media type |
| 17:21 |
|
BrunoC |
has it been adopted by the community? |
| 17:21 |
|
fumanchu |
no. I am not a community organizer. |
| 17:23 |
|
fumanchu |
the community appears to be working on a solution where the PATCH format is imperative code dressed up to look declarative |
| 17:23 |
|
whartung |
I thought the patch formats were, basically, patches… |
| 17:23 |
|
whartung |
i.e. trussed up diffs |
| 17:23 |
|
fumanchu |
they are. I think that's a fundamental mistake |
| 17:25 |
|
fumanchu |
they are trussed up diffs because they want to be able to express a diff of an arbitrarily complex tree structure |
| 17:25 |
|
whartung |
right |
| 17:25 |
|
fumanchu |
I find it's *so* much simpler to constrain the structure |
| 17:25 |
|
whartung |
they want to mechanically apply the diff to "anything" |
| 17:26 |
|
trygvis |
the generic patch format will obviously need to patch "anything" |
| 17:26 |
|
trygvis |
formats |
| 17:27 |
|
fumanchu |
Shoji already constrains the structure to encourage data boundaries that foster scalability. Because it's already constrained in that way, the PATCH format just "falls out" in a handful of paragraphs |
| 17:27 |
|
whartung |
fumanchu: you want something first class within the hypermedia format itself? so that the resource can represent it's data along with changes in the same media type? |
| 17:28 |
|
fumanchu |
yes. doesn't everybody? |
| 17:28 |
|
whartung |
apparently not :) |
| 17:28 |
|
fumanchu |
as I noted above, that seems to be what most ad-hoc solutions do in the wild |
| 17:28 |
|
fumanchu |
regardless of IETF WG's ;) |
| 17:29 |
|
whartung |
well, I think most ad hoc ones may use a similiar format, but they change the semantics in order to empower patch. I don't really know, I haven't looked at any in detail. |
| 17:34 |
|
whartung |
here's a quick nuggest for conversation, glancing at the Shoji spec above. The spec says it's "Shoji 2.0", the media-type is not versioned, nor is version apparently an element of the payload. Do you think it's suitable to have a payload with an OPTIONAL version element, and if the element does not exist within the payload, the system can "assume" that it's the "latest" version? |
| 17:35 |
|
fumanchu |
only in small deployments (like Shoji currently is) |
| 17:35 |
|
whartung |
ok |
| 17:36 |
|
BrunoC |
Do you know if patch is the standard adopted for partial updates? And how about the json patch? |
| 17:37 |
|
fumanchu |
patch is recommended for partial updates, yes. you can fake it with POST, but then the semantics are ad-hoc |
| 17:37 |
|
fumanchu |
PATCH allows you to have specified semantics with a much wider scope |
| 17:37 |
|
fumanchu |
everyone using that media type obeys the same semantics |
| 17:38 |
|
fumanchu |
(I dunno, maybe you could make a new media type for partial updates that you send with POST. but nobody does) |
| 17:41 |
|
fumanchu |
that's kind of the nub of my beef, now that I think about it |
| 17:41 |
|
fumanchu |
if you're going to invent a new media type just for PATCH, then why did we need PATCH in the first place? |
| 17:42 |
|
whartung |
does PATCH have different semantics than POST? |
| 17:42 |
|
whartung |
or just a different intent |
| 17:42 |
|
fumanchu |
a more narrow intent |
| 17:43 |
|
fumanchu |
the rationale of PATCH is kind of thin ;) |
| 17:43 |
|
fumanchu |
OST is already used but without broad interoperability (for one, there is no standard way to discover patch format support). |
| 17:43 |
|
fumanchu |
P* |
| 17:44 |
|
whartung |
how would you discover it with PATCH? |
| 17:44 |
|
BrunoC |
OST? |
| 17:45 |
|
BrunoC |
Well, I think PATCH is very useful for partial updates |
| 17:46 |
|
whartung |
the question boils down to how necessary are specializations of POST (or GET for that matter) |
| 17:46 |
|
BrunoC |
I'm looking at some APIs and what I have found is |
| 17:47 |
|
BrunoC |
some use PUT to partial updates and just ignore the readonly properties |
| 17:47 |
|
BrunoC |
others use actions on the URI (ugly, ugly) |
| 17:48 |
|
BrunoC |
using POST |
| 17:48 |
|
BrunoC |
I don't remember of any using POST for partial updates |
| 17:50 |
|
fumanchu |
https://developers.google.com/admin-sdk/directory/v1/guides/performance#patch |
| 17:51 |
|
fumanchu |
boy that looks like a Shoji PATCH. I oughtta ask for a job ;) |
| 17:52 |
|
whartung |
nah, they'll just take your work and corrupt it. :) |
| 17:52 |
|
fumanchu |
yeah. I'd never allow Shoji to grow ?fields=... |
| 17:52 |
|
fumanchu |
boom goes your caching |
| 17:59 |
|
BrunoC |
Why don't you like partial response? |
| 18:01 |
|
BrunoC |
Also, can you give me an example of a PATCH request using Shoji? I'm having a hard time trying to understand the difference between that and RFC5789 |
| 18:02 |
|
fumanchu |
at the protocol level, there's no such thing as a "partial response". there's only a response and another response. duplicating the same data across multiple responses makes cache synchronization, which is already a hard problem, insurmountable. |
| 18:03 |
|
fumanchu |
which one do I PUT to or PATCH? and then how do I invalidate all the other responses with that same data? |
| 18:03 |
|
BrunoC |
yes, but imagine that you know what changed and you only wants that information to update your local cache |
| 18:03 |
|
BrunoC |
I think partial response are useful in some cases |
| 18:04 |
|
BrunoC |
or another example |
| 18:04 |
|
BrunoC |
imagine a checkout service |
| 18:04 |
|
BrunoC |
and an ecommerce application |
| 18:05 |
|
BrunoC |
you might have a header with the total amount and total quantity |
| 18:05 |
|
BrunoC |
you know that you need to request the service every time (lets imagine that you do) |
| 18:05 |
|
|
tr3online joined #rest |
| 18:06 |
|
BrunoC |
for performance, you might find useful partial response with the total amount and total quantity |
| 18:07 |
|
trygvis |
you always work with full responses, if you want summaries/aggregates you'll find those as separate resources |
| 18:07 |
|
BrunoC |
like /cart/1/summary |
| 18:07 |
|
BrunoC |
? |
| 18:08 |
|
fumanchu |
trygvis: yes. Shoji has formalized that idea with separate Entity and View documents |
| 18:08 |
|
trygvis |
BrunoC: I don't care about its URL as long as discovered |
| 18:20 |
|
BrunoC |
just an example |
| 18:21 |
|
BrunoC |
that's an option, yeah, pretty cool actually for this scenario |
| 18:21 |
|
BrunoC |
so, e.g. /cart/1 will return all the cart information where the summary will have the link to /cart/1/summary to be used on the header |
| 18:22 |
|
BrunoC |
But, I may have a lot of fields in the summary that I don't need and maybe a partial response would help me |
| 18:27 |
|
BrunoC |
well, I'm having a good talk here, but I've to go, cya and thanks ;) |
| 18:28 |
|
fumanchu |
have fun |
| 18:29 |
|
mezod |
Hi, is there any standard on if PUT requests should always send full representations or only the modified fields? |
| 18:32 |
|
fumanchu |
yes. http://tools.ietf.org/html/rfc7231#section-4.3.4 was specifically revised from RFC 2616 to make it clear that PUT should not be partial. |
| 19:07 |
|
|
DrCode joined #rest |
| 19:14 |
|
|
tr3online joined #rest |
| 19:32 |
|
|
mezod_ joined #rest |
| 19:46 |
|
dreamdust |
mezod: Use PATCH to send a… patch. If you're using JSON use JSON-Patch. |
| 19:49 |
|
|
MLMitch joined #rest |
| 20:47 |
|
|
ruibritopt joined #rest |
| 20:48 |
|
|
marcoslamuria joined #rest |
| 21:08 |
|
|
marcoslamuria joined #rest |
| 22:14 |
|
|
ralphschindler joined #rest |
| 22:21 |
|
|
jackalista joined #rest |
| 22:53 |
|
|
BrunoC joined #rest |
| 23:21 |
|
|
locks joined #rest |
| 23:21 |
|
|
ruibritopt joined #rest |
| 23:22 |
|
|
mezod_ joined #rest |
| 23:22 |
|
|
CentaurWarchief joined #rest |
| 23:22 |
|
|
trygvis joined #rest |
| 23:22 |
|
|
ekroon joined #rest |
| 23:22 |
|
|
zama joined #rest |
| 23:23 |
|
|
asm89 joined #rest |
| 23:27 |
|
|
riddle joined #rest |
| 23:34 |
|
|
marcoslamuria joined #rest |
| 23:52 |
|
|
DrCode joined #rest |
