| Time |
S |
Nick |
Message |
| 00:20 |
|
fumanchu_ |
https://tools.ietf.org/html/rfc7230#section-2.7.1 |
| 00:30 |
|
|
jcromartie joined #rest |
| 00:34 |
|
|
SlippinJimmy joined #rest |
| 01:50 |
|
|
shrink0r_ joined #rest |
| 02:01 |
|
|
SupaHam joined #rest |
| 02:03 |
|
|
SupaHam joined #rest |
| 05:16 |
|
|
tr3online joined #rest |
| 06:40 |
|
|
_ollie joined #rest |
| 06:51 |
|
|
tr3online joined #rest |
| 06:53 |
|
|
rosstuck joined #rest |
| 07:58 |
|
|
tr3online joined #rest |
| 08:46 |
|
|
azer_ joined #rest |
| 09:24 |
|
|
vanHoesel joined #rest |
| 09:34 |
|
|
SupaHam joined #rest |
| 09:48 |
|
|
Left_Turn joined #rest |
| 09:54 |
|
|
tr3online joined #rest |
| 09:55 |
|
|
jcromartie joined #rest |
| 10:21 |
|
|
shrink0r joined #rest |
| 10:36 |
|
|
Left_Turn joined #rest |
| 11:10 |
|
|
jcromartie joined #rest |
| 11:10 |
|
|
tr3online joined #rest |
| 13:01 |
|
|
azer_ joined #rest |
| 13:12 |
|
|
azer_ joined #rest |
| 13:13 |
|
|
mezod joined #rest |
| 13:35 |
|
|
graste joined #rest |
| 14:48 |
|
|
tr3online joined #rest |
| 14:52 |
|
ramsey |
pdurbin: Hey. Yes, I’ve met bigbluehat, too. :-) |
| 15:18 |
|
|
_ollie joined #rest |
| 15:45 |
|
|
hackel joined #rest |
| 17:02 |
|
|
HighBit joined #rest |
| 17:12 |
|
|
_ollie joined #rest |
| 17:36 |
|
|
_ollie joined #rest |
| 18:16 |
|
|
tr3online joined #rest |
| 18:30 |
|
|
lemur joined #rest |
| 18:47 |
|
|
hackel joined #rest |
| 18:48 |
|
|
tieTYT2 joined #rest |
| 18:48 |
|
tieTYT2 |
i’d love some feedback on this question, thanks: http://stackoverflow.com/questions/29217663/is-this-a-restful-way-to-handle-multiple-verbs-for-a-resource |
| 18:50 |
|
trygvis |
no, you're creating many URLs to the same resource |
| 18:51 |
|
trygvis |
and it is very RPC in its style, you should stick to a single resource and send full updates |
| 18:51 |
|
whartung |
You can post the URL to clone to the /clone reousrce. You can treat locks as first class resources as well. PUBLISH is a state that you can modify within the resoruce. |
| 18:53 |
|
trygvis |
I'd do post the lock attribute as a part of the resource too |
| 18:53 |
|
whartung |
POST /lock^M/cms/objects/3232/drafts/1 -> 302 /lock/1234 |
| 18:54 |
|
tieTYT2 |
what if you can only lock drafts? |
| 18:54 |
|
whartung |
GET /lock (lists all current locks); DELETE /lock/1234 unlocks it., etc. |
| 18:54 |
|
whartung |
enforce that at the lock resource |
| 18:54 |
|
trygvis |
having a separate lock resource is nice if you want to lock more than one resource |
| 18:55 |
|
tieTYT2 |
ok what about the fact that you need an object id and a draft id to identify a draft? |
| 18:55 |
|
trygvis |
but otherwise I would stick to an attribute on the resource |
| 18:55 |
|
tieTYT2 |
trygvis: attribute = query param? |
| 18:55 |
|
tieTYT2 |
or something in the body I send over? |
| 18:56 |
|
trygvis |
in the body, it is a part of the resource's state |
| 18:57 |
|
tieTYT2 |
i’ll see if I can do that. I have a feeling some crazy black magic happens on the backend that will prevent me from making it that easy |
| 18:58 |
|
tieTYT2 |
ok what about the fact that you need an object id and a draft id to identify a draft? Should I have DELETE /lock?objectId=foo&draftId=bar ? |
| 18:59 |
|
whartung |
no, when you create the lock, you get an identifer that represensts that lock |
| 19:00 |
|
whartung |
you post the URL to /lock, and get /lock/1234 back |
| 19:00 |
|
whartung |
that's your lock |
| 19:01 |
|
tieTYT2 |
ah, I’m pretty sure it already works differently in the backend |
| 19:01 |
|
tieTYT2 |
and I don’t have control over that part |
| 19:01 |
|
whartung |
REST is about REPRESENTATIONS, the fact that it "looks different" on the back end is a presentation issue. |
| 19:02 |
|
whartung |
you're not trying to map 1:1 or leak out your implementation to the REST space. |
| 19:02 |
|
tieTYT2 |
yeah but wouldn’t I have to add something to the persistence layer to hold these new lock ids? |
| 19:02 |
|
whartung |
I dunno, depends on how you manage your locks. |
| 19:02 |
|
whartung |
basically |
| 19:03 |
|
whartung |
if you thing that "DELETE /lock?objectId=1" is ok, then you can simply persist that identifier internally, and when the LOCK resource is deleted, it performs the operations on the back end. |
| 19:03 |
|
trygvis |
tieTYT2: you could encode that in the URL you give back to the user |
| 19:03 |
|
trygvis |
but the client will never know that fact as it doesn't care how the URL look |
| 19:03 |
|
whartung |
also, objectId=foo&draftId=bar should not be your idenetifier. The identifier for the resource is the URL. |
| 19:04 |
|
|
zama joined #rest |
| 19:05 |
|
|
asm89 joined #rest |
| 19:06 |
|
tieTYT2 |
whartung: what about DELETE /lock/objects/objectId/drafts/draftId ? |
| 19:07 |
|
tieTYT2 |
if I can’t persist new fields |
| 19:07 |
|
tieTYT2 |
oh I guess you already said that at the top |
| 19:07 |
|
whartung |
well, as trygvis mentioned, with a first class lock resource, you can lock all sorts of things in a batch. here you're leaking a whole bunch of information and encoding it in the URL. |
| 19:08 |
|
whartung |
I mean, that's fine, as long as you don't expect the client to assemble those URLs as well. |
| 19:08 |
|
tieTYT2 |
yes but if I want to lock something else, isn’t it as simple as DELETE /lock/somethingelse/somethingelseId ? |
| 19:08 |
|
whartung |
the client will just DELETE <URL> like normal |
| 19:09 |
|
whartung |
have to step away to lunch, we can talk when I get back i fyou have more questions. |
| 19:10 |
|
tieTYT2 |
cool, thanks |
| 19:10 |
|
tieTYT2 |
see ya |
| 19:29 |
|
|
shrink0r joined #rest |
| 20:01 |
|
|
digitalsanctum joined #rest |
| 20:02 |
|
|
graste joined #rest |
| 20:03 |
|
|
hackel joined #rest |
| 20:56 |
|
|
hackel joined #rest |
| 21:40 |
|
|
fumanchu joined #rest |
| 23:03 |
|
|
fumanchu_ joined #rest |
| 23:14 |
|
|
lemur joined #rest |
