| Time |
S |
Nick |
Message |
| 01:16 |
|
|
fumanchu_ joined #rest |
| 01:36 |
|
|
fuzzyhorns joined #rest |
| 01:45 |
|
|
fuzzyhorns joined #rest |
| 02:01 |
|
|
fuzzyhorns joined #rest |
| 02:05 |
|
|
_ollie joined #rest |
| 02:24 |
|
|
wsiqueir joined #rest |
| 02:55 |
|
|
baweaver joined #rest |
| 03:39 |
|
|
fuzzyhorns joined #rest |
| 03:52 |
|
|
locks joined #rest |
| 04:01 |
|
|
rickharrison joined #rest |
| 04:02 |
|
|
ChrisAnn joined #rest |
| 04:04 |
|
|
bigbluehat joined #rest |
| 04:23 |
|
|
ekroon joined #rest |
| 04:24 |
|
|
angular_mike_ joined #rest |
| 04:38 |
|
|
FreezingDroid joined #rest |
| 04:52 |
|
|
wsiqueir joined #rest |
| 05:02 |
|
|
FreezingDroid joined #rest |
| 05:06 |
|
|
huckleberry78 joined #rest |
| 05:14 |
|
|
huckleberry78 joined #rest |
| 05:54 |
|
|
baweaver joined #rest |
| 07:16 |
|
|
rosstuck joined #rest |
| 07:26 |
|
|
benaiah joined #rest |
| 07:53 |
|
|
huckleberry78 joined #rest |
| 08:32 |
|
|
interop_madness joined #rest |
| 08:37 |
|
|
graste joined #rest |
| 08:45 |
|
|
huckleberry78 joined #rest |
| 08:56 |
|
|
quimrstorres joined #rest |
| 12:16 |
|
|
huckleberry78 joined #rest |
| 12:28 |
|
|
fumanchu joined #rest |
| 12:33 |
|
|
Jarda joined #rest |
| 13:14 |
|
|
quimrstorres joined #rest |
| 13:48 |
|
|
quimrstorres joined #rest |
| 13:51 |
|
|
fuzzy_horns joined #rest |
| 14:01 |
|
|
rosstuck joined #rest |
| 14:09 |
|
|
happyface joined #rest |
| 14:17 |
|
|
huckleberry78 joined #rest |
| 14:40 |
|
|
wsiqueir joined #rest |
| 15:09 |
|
|
quimrstorres joined #rest |
| 15:13 |
|
|
dEPy joined #rest |
| 15:15 |
|
|
quimrstorres joined #rest |
| 15:57 |
|
|
foist joined #rest |
| 16:34 |
|
|
baweaver joined #rest |
| 17:07 |
|
|
_ollie joined #rest |
| 17:09 |
|
|
fuzzy__horns joined #rest |
| 17:38 |
|
|
sfisque joined #rest |
| 20:19 |
|
|
happyface joined #rest |
| 21:13 |
|
|
Coldblackice joined #rest |
| 21:24 |
|
|
travelr joined #rest |
| 21:25 |
|
travelr |
so it just ocured to me you can tunnel any method call through REST if you give it a mime type |
| 21:25 |
|
travelr |
j web |
| 21:25 |
|
travelr |
Oh dan |
| 21:26 |
|
travelr |
Anyway |
| 21:26 |
|
travelr |
Point is we are nt limited to HTTP's methiods |
| 21:26 |
|
travelr |
Why am I typing like a monkey today |
| 21:29 |
|
|
fumanchu joined #rest |
| 21:30 |
|
travelr |
Is anyone doing this - separate mime type for every action |
| 21:31 |
|
whartung |
you were never limited by HTTPs methods |
| 21:32 |
|
travelr |
whartung: well I'm "limited" to the degree if I start inventing my own, intermediaries won't understand them (and most times the other side, be it server or client) |
| 21:33 |
|
travelr |
whartung: how do you expand the method vocabulary yourself |
| 21:36 |
|
fumanchu |
the set of HTTP methods was designed to be extensible |
| 21:36 |
|
fumanchu |
too bad most implementations don't know that and choke |
| 21:37 |
|
travelr |
fumanchu: extensible doens't mean Joe can sit down and add methods. |
| 21:37 |
|
travelr |
It's extensible inly if all parties agree on the extension |
| 21:37 |
|
travelr |
Which is rare |
| 21:37 |
|
fumanchu |
or ignore it |
| 21:37 |
|
fumanchu |
which is rarer |
| 21:37 |
|
travelr |
*shrug* |
| 21:38 |
|
* fumanchu |
blames HTML |
| 21:38 |
|
whartung |
basically none of your extensions can expect intermediaries to enforce idempotency |
| 21:38 |
|
whartung |
that's about the limit of it. |
| 21:38 |
|
whartung |
proxies will just pass it through, treat them as a POST |
| 21:39 |
|
whartung |
but, anyway, WebDAV is the most notable protocol that extended the HTTP verb set. |
| 21:40 |
|
* fumanchu |
recalls the guy who argued with me here a couple months ago and said he wrote his own HTTP server. I wonder if he passes through unknown verbs >;) |
| 21:40 |
|
whartung |
using content type as a verb seems kinda stinky to me, as the media types are ostensibly supposed to be a but limited |
| 21:40 |
|
whartung |
heh |
| 21:40 |
|
travelr |
whartung: well not as a verb per se |
| 21:40 |
|
fumanchu |
you know, like "PATCH" |
| 21:40 |
|
travelr |
sort of let's think... |
| 21:41 |
|
whartung |
yea, the framework I use would just punt on them…silently fail with them. |
| 21:41 |
|
travelr |
POST + mime "thing-constructor" |
| 21:41 |
|
travelr |
PATCH + "thing-partial-fieldset" |
| 21:41 |
|
whartung |
POST /doit Content-Type:MySpecialThing |
| 21:41 |
|
travelr |
PATCH is like giving up, I don't know why they added it |
| 21:42 |
|
travelr |
Basically you try: GET? POST? DELETE? PUT? ... I give up, I'll shove it in PATCH |
| 21:42 |
|
whartung |
eh, I can see the need for an incemental update. |
| 21:42 |
|
travelr |
That's not the issue, the issue is POST already allowed for this. |
| 21:42 |
|
whartung |
we're messing with optimistic locking, if we had PATCH, I wouldn't bother, or at least it would be less important. |
| 21:43 |
|
travelr |
Creating new subentity is only *one* of the possible meanings of POST |
| 21:43 |
|
whartung |
POST is the garbage can of HTTP. |
| 21:43 |
|
whartung |
POST can be "anything" |
| 21:43 |
|
travelr |
Was. Now PATCH is :P |
| 21:43 |
|
whartung |
so, yea, POST can be PATCH |
| 21:43 |
|
fumanchu |
I rely heavily on PATCH, but then, I designed my primary media type specifically to be its own PATCH format |
| 21:44 |
|
whartung |
POST is still the catch all, moreso than PATCH |
| 21:45 |
|
whartung |
what format is that fumanchu ? |
| 21:46 |
|
fumanchu |
https://bitbucket.org/fumanchu/shoji/src/tip/spec.txt?at=default#cl-705 |
| 21:47 |
|
whartung |
I've seen a JSON patch format -- boy is it ugly |
| 21:47 |
|
fumanchu |
yeah :( |
| 21:47 |
|
fumanchu |
"any JSON" is way too generic for that to be anything but ugly |
| 21:48 |
|
whartung |
do you have an example of a patch payload? |
| 21:48 |
|
whartung |
yea |
| 21:48 |
|
* fumanchu |
looks |
| 21:49 |
|
fumanchu |
not per se, but if you look at the examples in https://github.com/Crunch-io/pycrunch/blob/master/README.md |
| 21:50 |
|
fumanchu |
any of those "Catalog" objects, for example, would be PATCHable by just constructing one with the attributes you want to change |
| 21:50 |
|
fumanchu |
(in the "index" member) |
| 21:50 |
|
whartung |
how do you delete an element |
| 21:50 |
|
fumanchu |
by constraining the editable data to the "index" member in a standard format, the PATCH format also becomes standard |
| 21:51 |
|
|
FreezingDroid joined #rest |
| 21:51 |
|
fumanchu |
you can remove a member from a catalog.index via index = {key: null} |
| 21:51 |
|
fumanchu |
(not all catalogs support that) |
| 21:51 |
|
fumanchu |
only those which contain their members |
| 21:51 |
|
whartung |
so catalogs are collections of elements which are collecitons of attributes? |
| 21:52 |
|
fumanchu |
essentially, yes |
| 21:52 |
|
whartung |
do you support simple collectiions, or are they all keyed? i.e. simple lists |
| 21:52 |
|
fumanchu |
catalogs typically expose some attributes of each collected entity |
| 21:53 |
|
fumanchu |
not as a catalog, but there are other places you can |
| 21:53 |
|
fumanchu |
the catalog.index is always keyed (by URL actually, not just any string) |
| 21:54 |
|
whartung |
heh -- namespaces.. |
| 21:54 |
|
fumanchu |
catalogs expose attributes that are useful for ordering or selecting entities from the collection. if you follow the link to the entity resource it likely has lots more attrs |
| 21:55 |
|
whartung |
but I like :null to delete something, just not sure how I would remove "2" from [1, 2, 3] |
| 21:55 |
|
fumanchu |
attrs[key] = [1, 3] |
| 21:55 |
|
fumanchu |
;) |
| 21:56 |
|
whartung |
because I have to capture delta changes to my java objects in order facilitate optimistic locking and retries |
| 21:56 |
|
whartung |
so it's simply enough to extend that to a differential "patch", to a point... |
| 21:56 |
|
fumanchu |
sure |
| 21:57 |
|
whartung |
well your example brings up the case of changes to nested entities. |
| 21:57 |
|
whartung |
(to use your vocabulary) |
| 21:58 |
|
fumanchu |
there's no such thing as a "nested entity" in Shoji. only related ones. |
| 21:58 |
|
whartung |
ic |
| 21:58 |
|
fumanchu |
which surprisingly helps you constrain your API to be scalable by default |
| 21:59 |
|
whartung |
how do you mean? |
| 22:00 |
|
fumanchu |
if you "nest" entities in one resource, you can't by definition have some entities live on one system/host/domain and some on another |
| 22:00 |
|
whartung |
yup, true |
| 22:01 |
|
fumanchu |
nested entities, especially if they are editable, also makes cache invalidation exponentially harder |
| 22:01 |
|
whartung |
si |
| 22:01 |
|
whartung |
it's the "coarse" vs "chatty" trade off. |
| 22:02 |
|
fumanchu |
somewhat |
| 22:02 |
|
fumanchu |
most of the time with Shoji you just expose the attrs you need in the catalog to avoid chattiness |
| 22:04 |
|
fumanchu |
if I didn't have a day job, I'd spend all day telling people I would port their existing API to Shoji, which would only be painful where their existing API needed improvement. Satisfaction guaranteed or your money back. |
| 22:04 |
|
whartung |
be interesting to see if it could support the crushing weight of healthcare. |
| 22:05 |
|
fumanchu |
healthcare, yes. genomic analysis, probably not the right fit ;) |
| 22:06 |
|
whartung |
healthcare an ugly business |
| 22:06 |
|
whartung |
*is an |
| 22:06 |
|
whartung |
but I like the idea, especially if you tie it in with some batching. |
| 22:07 |
|
whartung |
batching and caching helps make links "free". |
| 22:07 |
|
whartung |
at least, cheaper |
| 22:08 |
|
fumanchu |
the other pitch I have is: architecture is all about constraints. And Shoji's constraints have certainly allowed me to be more hands-off with our API devs. They've been steered away from horrible slow broken designs countless times. |
| 22:08 |
|
whartung |
use a BATCH verb, pass in a list of links, get a MIME payload back. |
| 22:08 |
|
whartung |
constraints make it easier to say no :) |
| 22:09 |
|
whartung |
for example |
| 22:09 |
|
whartung |
right now |
| 22:09 |
|
whartung |
we have a User resource, for our authn/authz system |
| 22:10 |
|
whartung |
and we bundle the roles within the resource |
| 22:10 |
|
whartung |
rather than have /user/{id}/roles, for example |
| 22:10 |
|
whartung |
but I know our folks won't cache squat, so…better to keep it "less" chatty. |
| 22:11 |
|
fumanchu |
sure |
| 22:11 |
|
whartung |
of course, roles is (should be) smaller enough to be treated as a "whole", evn in a patch -- send the entire edited list back, for example. |
| 22:12 |
|
fumanchu |
I was just typing that |
| 22:12 |
|
whartung |
which is another reason I did that |
| 22:12 |
|
fumanchu |
and if it's not, it's probably too big to include them all in one resource |
| 22:12 |
|
whartung |
right |
| 22:12 |
|
whartung |
doesn'tr make sense |
| 22:12 |
|
whartung |
but I like the "prop:null" bit, I may steal that and make my stuff "patchable" |
| 22:13 |
|
whartung |
because I've already floated the Optimistic locking issue, and no one has pushed back yet |
| 22:13 |
|
whartung |
but I don't think they quite grok what it means in terms of them having to retry and merge stuff. |
| 22:14 |
|
whartung |
(or they'll be extra lazy and push an error to the user…"thanks a lot") |
| 22:16 |
|
fumanchu |
:) |
| 22:17 |
|
whartung |
I also expect them to simply steal the etag and stomp the resource anyway. |
| 22:17 |
|
fumanchu |
prop:null works for Shoji Catalogs because prop:object is required otherwise. make sure you don't delete something someone's trying to make truly null |
| 22:20 |
|
whartung |
well, I guess the key point is to use "null" as, well…'null'. that it's a "keyword" so to speak. So { "prop": null } is different from {"prop" : "null" }. And the fact that we now have a first class null, we can submit a partial resource. Properties that aren't there at all are skipped, null lets us set actual properties to null. |
| 22:20 |
|
whartung |
because that's always the issue, how to interpret missing properties in order to handle a partial submission |
| 22:20 |
|
whartung |
first class null lets us manage that |
| 22:21 |
|
fumanchu |
cool |
| 22:44 |
|
|
fuzzyhorns joined #rest |
| 22:59 |
|
|
huckleberry78 joined #rest |
| 23:56 |
|
|
blahdeblah joined #rest |
