| Time |
S |
Nick |
Message |
| 01:49 |
|
|
shrink0r_ joined #rest |
| 02:04 |
|
|
mezod joined #rest |
| 02:28 |
|
|
lemur joined #rest |
| 03:18 |
|
|
fumanchu joined #rest |
| 07:27 |
|
|
tr3online joined #rest |
| 07:56 |
|
|
shrink0r joined #rest |
| 08:43 |
|
|
EnergyCoffee joined #rest |
| 08:43 |
|
|
shrink0r joined #rest |
| 09:06 |
|
|
graste joined #rest |
| 09:38 |
|
|
shrink0r joined #rest |
| 10:15 |
|
|
Left_Turn joined #rest |
| 10:30 |
|
|
interop_madness joined #rest |
| 11:57 |
|
|
vanHoesel joined #rest |
| 12:55 |
|
|
graste joined #rest |
| 13:01 |
|
|
mezod joined #rest |
| 14:51 |
|
|
aGHz joined #rest |
| 16:31 |
|
|
lemur_ joined #rest |
| 16:41 |
|
|
cigarshark joined #rest |
| 17:00 |
|
|
ModusPwnens_ joined #rest |
| 17:00 |
|
ModusPwnens_ |
How does one pass audit information in a put, post, edit, or delete request in a restful way? |
| 17:16 |
|
|
tieTYT2 joined #rest |
| 17:28 |
|
trygvis |
ModusPwnens_: if you mean stuff like correlation ids and stuff like that I think your options are 1) as specified by your media type or 2) invent your own header and semantics around that |
| 17:29 |
|
trygvis |
I haven't seen much around standardization in that area |
| 17:29 |
|
ModusPwnens_ |
Correlation IDs would be an example, or just more generally, a 'reason' for editing or changing a particular resource |
| 17:29 |
|
ModusPwnens_ |
it really doesn't make sense to pass that information inside the models you are editing as those aren't really attributes of the model |
| 17:30 |
|
ModusPwnens_ |
but I don't actually know how to do that 'restfully' |
| 17:30 |
|
trygvis |
well, in a REST context that is not unusual |
| 17:30 |
|
ModusPwnens_ |
when you do posts, do you just post two items? The actual resource you are changing and then maybe post another subresource which could be the 'audit detail' subresource along with it? |
| 17:30 |
|
fumanchu |
I wouldn't sweat that too much. But on the other hand, my preferred media type has an explicit "body" for just that kind of distinction |
| 17:31 |
|
ModusPwnens_ |
we are basically using json as our data format |
| 17:34 |
|
trygvis |
{reason: {..}, body:{..}} would work. I would always return a body field to keep it as consistent as possible |
| 17:40 |
|
whartung |
audit infromation is meta data |
| 17:40 |
|
whartung |
so, yea, I'd either use a header, or a meta data aware payload |
| 17:40 |
|
whartung |
depends on what you're tyring to audit |
| 17:44 |
|
ModusPwnens_ |
this is basically a financial system, .e.g. creating accounts, updating accounts, posting transactions, etc etc |
| 17:44 |
|
ModusPwnens_ |
so we need to be able to know who did what, when, and why |
| 17:46 |
|
ModusPwnens_ |
honestly, if we didn't have to pass a reference ID or a 'reason for editing', then this could simply be using remote_user or something. But, now we are getting into a scenario where users can provide information about why they are changing something |
| 17:46 |
|
ModusPwnens_ |
and i feel like it's a little weird to be putting user provided information like that in a header |
| 17:46 |
|
fumanchu |
agreed |
| 17:47 |
|
ModusPwnens_ |
so if it doesn't go in a header, and it doesn't go inside whatever resource you are posting, what is the right way? Considering 'audit detail' as a subresource of every resource and posting both of them for posts, puts, updates, and deletes? |
| 17:48 |
|
fumanchu |
yuck |
| 17:49 |
|
fumanchu |
I'd rather POST a multipart than have a subresource |
| 17:49 |
|
ModusPwnens_ |
what do you mean? |
| 17:49 |
|
fumanchu |
(and that's saying something) |
| 17:51 |
|
fumanchu |
POSTing to a 2nd resource every time you make a change is going to seriously hamper efficiency and coherency of your API |
| 17:51 |
|
fumanchu |
twice the packets, four times the sync problems |
| 17:53 |
|
ModusPwnens_ |
fumanchu: I don't mean two separate requests. I mean having something like this as the post data: { transaction: { more stuff}, audit_detail: {audit information} } |
| 17:53 |
|
whartung |
well, what's worse is that if you can post the audit separetly, well, then you don't have to post it at all -- kind of breaks the cahin of trust. Requiring with the payload can be validated. |
| 17:53 |
|
fumanchu |
ah whew |
| 17:53 |
|
ModusPwnens_ |
and then when the service gets that info, it pulls out transaction and updates the resource |
| 17:53 |
|
fumanchu |
sorry, I'm used to "subresource" meaning "foo/bar is a subresource of foo/" |
| 17:54 |
|
ModusPwnens_ |
well, yeah. so later if you wanted to get a list of audit information for you |
| 17:54 |
|
ModusPwnens_ |
you could go do something like GET /transaction/123/audits |
| 17:54 |
|
fumanchu |
since HTTP URI's have hierarchical path components, not opaque ones (/me elbows trygvis ;) |
| 17:54 |
|
whartung |
:) |
| 17:55 |
|
fumanchu |
ModusPwnens_: that sounds entirely reasonable |
| 17:56 |
|
ModusPwnens_ |
is it also reasonable to do the rest updates that way? It basically means that you are required to have audit_information alongside whatever else you are updating otherwise the request will fail |
| 17:56 |
|
fumanchu |
there's no problem at all with one POST causing multiple URI's to start returning 200 instead of 404 |
| 17:56 |
|
fumanchu |
sure; your API can sepcify any constraints it likes on top of what the media type specifies |
| 17:56 |
|
ModusPwnens_ |
additionally, it means we would be doing an update of the "/transaction/123" root resource and an update of some /transaction/123/audits resource at the same time for one request |
| 17:57 |
|
fumanchu |
not a problem; happens all the time |
| 17:57 |
|
ModusPwnens_ |
hmm okay |
| 17:57 |
|
ModusPwnens_ |
i think I'll look into doing it this way then. Thanks! |
| 17:57 |
|
ModusPwnens_ |
this seems like the sanest way of doing what i want |
| 17:58 |
|
ModusPwnens_ |
oh, one last question: With REST, if you have a resource /foo and a subresource /foo/bar, is it expected that if you GET /foo, you also get /bar? |
| 17:58 |
|
fumanchu |
no |
| 17:58 |
|
fumanchu |
that's an antipattern |
| 17:59 |
|
fumanchu |
if you want to return bar info with foo, then publish them both at foo/ without a separate foo/bar/ endpoint |
| 18:00 |
|
fumanchu |
and let caching provide network efficiency |
| 18:00 |
|
ModusPwnens_ |
OK, makes sense. So how does a client know about /foo/bar from getting /foo then? |
| 18:00 |
|
ModusPwnens_ |
or is a client not expected to know that? |
| 18:02 |
|
fumanchu |
if you have a Foo resource and a Bar resource, you can: 1) publish them together in one payload at foo/ or 2) publish Foo at foo/ and Bar at foo/bar |
| 18:02 |
|
fumanchu |
you make that choice generally by looking at access patterns, particularly transaction boundaries |
| 18:03 |
|
fumanchu |
a client knows about foo/bar by following a link, often one that is returned with foo/ |
| 18:03 |
|
fumanchu |
(if you're in scenario 2) |
| 18:04 |
|
fumanchu |
but in scenario 1, there is no foo/bar URI |
| 18:05 |
|
fumanchu |
you have to take the resources you have on the server, typically OO objects, and figure out how those map to URI's. It's almost never 1:1. |
| 18:12 |
|
|
tr3online joined #rest |
| 18:26 |
|
ModusPwnens_ |
Well, if I do it the way i'm talking about |
| 18:55 |
|
|
graste joined #rest |
| 19:50 |
|
|
shrink0r joined #rest |
| 20:05 |
|
|
tieTYT2 joined #rest |
| 20:08 |
|
vanHoesel |
ModusPwnens_ and others... |
| 20:08 |
|
ModusPwnens_ |
Oops, i partially filled out a message and accidentally hit 'enter' :P |
| 20:08 |
|
vanHoesel |
... why not create a new resource 'mutations' and post three things: |
| 20:09 |
|
vanHoesel |
1) the canonical URI |
| 20:09 |
|
vanHoesel |
2) the audit data |
| 20:09 |
|
vanHoesel |
3) the payload |
| 20:10 |
|
vanHoesel |
now... one can only do GET on the canonical URI for the account |
| 20:10 |
|
trygvis |
that is one way to create transaction-like resources |
| 20:11 |
|
trygvis |
then you'll need a fourth call to tell the server that all the data is uploaded and have it create all the resources |
| 20:12 |
|
ModusPwnens_ |
so should we be changing the way we are thinking about our resources? Instead of directly changing a 'resource', should we just be posting transactions/operations that affect that resource? |
| 20:12 |
|
vanHoesel |
urm ... 1 call to send all three things, ofcourse |
| 20:13 |
|
vanHoesel |
i don't say you need to change the way you think about your resources, it's just how i think about it |
| 20:13 |
|
ModusPwnens_ |
TBH, this whole system we are designing is a bit headache inducing because we have several services in charge of different things, but a single workflow might require several services to commit changes to one another. Which is a nightmare for failure cases |
| 20:14 |
|
vanHoesel |
doing POSTs to a /mutations feels like setting up a queue - which has it's own merrits - and drawbacks |
| 20:16 |
|
ModusPwnens_ |
Yeah and we want to avoid a queue or pubsub type design due to the distributed yet occaisonally coupled nature of our services |
| 20:16 |
|
ModusPwnens_ |
Which is another problem I really wish I had a better solution for |
| 20:23 |
|
t_dot_zilla |
so it's not good practice to use verbs in the URI ? |
| 20:23 |
|
|
graste joined #rest |
| 20:32 |
|
vanHoesel |
Hmmm ... ModusPwnens_ what about only allowing PATCH for any updates? |
| 20:33 |
|
ModusPwnens_ |
isn't that mostly just a semantic difference? |
| 20:34 |
|
vanHoesel |
application/json-patch+json has it's own structure, and does not forbid adding extra members to the operation array... one could add audit datata that can be recorded in your auditing system - seperatly from the resource |
| 20:35 |
|
|
hackel joined #rest |
| 21:49 |
|
|
hackel joined #rest |
| 21:49 |
|
|
graste joined #rest |
| 21:49 |
|
|
tieTYT2 joined #rest |
| 21:49 |
|
|
shrink0r joined #rest |
| 21:49 |
|
|
tr3online joined #rest |
| 21:49 |
|
|
ModusPwnens_ joined #rest |
| 21:49 |
|
|
cigarshark joined #rest |
| 21:49 |
|
|
aGHz joined #rest |
| 21:49 |
|
|
mezod joined #rest |
| 21:49 |
|
|
vanHoesel joined #rest |
| 21:49 |
|
|
Left_Turn joined #rest |
| 21:49 |
|
|
EnergyCoffee joined #rest |
| 21:49 |
|
|
fumanchu joined #rest |
| 21:49 |
|
|
asm89 joined #rest |
| 21:49 |
|
|
zama joined #rest |
| 21:49 |
|
|
HighBit joined #rest |
| 21:49 |
|
|
SupaHam joined #rest |
| 21:49 |
|
|
rosstuck joined #rest |
| 21:49 |
|
|
SlippinJimmy joined #rest |
| 21:49 |
|
|
mgomezch joined #rest |
| 21:49 |
|
|
imanc_ joined #rest |
| 21:49 |
|
|
ekroon joined #rest |
| 21:49 |
|
|
bigbluehat joined #rest |
| 21:49 |
|
|
Doc-Saintly joined #rest |
| 21:49 |
|
|
whartung joined #rest |
| 21:49 |
|
|
pindonga joined #rest |
| 21:49 |
|
|
daxim joined #rest |
| 21:49 |
|
|
blahdeblah_ joined #rest |
| 21:49 |
|
|
igitoor joined #rest |
| 21:49 |
|
|
Davey joined #rest |
| 21:49 |
|
|
t_dot_zilla joined #rest |
| 21:49 |
|
|
StatelessCat joined #rest |
| 21:49 |
|
|
dkm joined #rest |
| 21:49 |
|
|
pdurbin joined #rest |
| 21:49 |
|
|
jgornick joined #rest |
| 21:49 |
|
|
spaceone joined #rest |
| 21:49 |
|
|
sulky joined #rest |
| 21:49 |
|
|
ironChicken joined #rest |
| 21:49 |
|
|
gamache joined #rest |
| 21:49 |
|
|
csgeek joined #rest |
| 21:49 |
|
|
trygvis joined #rest |
| 21:49 |
|
|
dreamdust joined #rest |
| 21:49 |
|
|
`0660 joined #rest |
| 21:49 |
|
|
alxbl joined #rest |
| 21:49 |
|
|
upasana joined #rest |
| 21:49 |
|
|
blindscreen_ joined #rest |
| 21:49 |
|
|
Guest18878 joined #rest |
| 21:49 |
|
|
ChrisAnn joined #rest |
| 21:49 |
|
|
benaiah joined #rest |
| 21:49 |
|
|
asdf` joined #rest |
| 21:49 |
|
|
rickharrison joined #rest |
| 21:49 |
|
|
ramsey joined #rest |
| 21:49 |
|
|
tmoore joined #rest |
| 21:49 |
|
|
lebster joined #rest |
| 21:49 |
|
|
locks joined #rest |
| 21:49 |
|
|
CentaurWarchief joined #rest |
| 21:49 |
|
|
riddle joined #rest |
| 23:09 |
|
|
tieTYT2 joined #rest |
| 23:45 |
|
|
shrink0r_ joined #rest |
