| Time |
S |
Nick |
Message |
| 00:03 |
|
|
_ollie joined #rest |
| 00:33 |
|
|
fuzzyhorns joined #rest |
| 02:27 |
|
|
_ollie joined #rest |
| 02:38 |
|
|
fuzzyhorns joined #rest |
| 02:45 |
|
|
fuzzyhorns joined #rest |
| 02:50 |
|
|
baweaver joined #rest |
| 03:26 |
|
|
baweaver joined #rest |
| 03:30 |
|
|
jgornick joined #rest |
| 03:30 |
|
|
dkm joined #rest |
| 03:31 |
|
|
_ollie joined #rest |
| 03:47 |
|
|
baweaver joined #rest |
| 04:03 |
|
|
dkm joined #rest |
| 04:04 |
|
|
jgornick joined #rest |
| 07:05 |
|
|
rosstuck joined #rest |
| 07:09 |
|
|
timg___ joined #rest |
| 07:16 |
|
|
talios joined #rest |
| 07:16 |
|
|
talios joined #rest |
| 07:16 |
|
|
interop_madness joined #rest |
| 07:17 |
|
|
timg___ joined #rest |
| 07:39 |
|
|
azr joined #rest |
| 08:27 |
|
|
timg___ joined #rest |
| 09:01 |
|
|
timg___ joined #rest |
| 09:13 |
|
|
timg___ joined #rest |
| 09:22 |
|
|
pokEarl joined #rest |
| 09:30 |
|
interop_madness |
suppose a client requests a resource with Accept: text/xml. but the only XML-based media type that the server can return is a custom application/vnd.contoso.mytype+xml. is it ok to return said representation or should the server rather say "406 NO STACKENBLOCHEN"? |
| 09:49 |
|
blongden |
You can return whatever you like |
| 09:49 |
|
trygvis |
I doubt anyone would say text/xml and be able to consume application/vnd.contoso.mytype+xml |
| 09:49 |
|
blongden |
Or you can return 406. |
| 09:50 |
|
blongden |
Depends on the client really. If the client only supports xml, then returning application/vnd.contoso.mytype+xml and doing something xml-y with it is ok. |
| 09:50 |
|
blongden |
If that's not appropriate or required then the 406 is OK too. Whichever you like. :) |
| 09:51 |
|
trygvis |
yeah, but nobody really does xml-y things, they almost always require a particular format |
| 09:51 |
|
blongden |
xml formatters do |
| 09:51 |
|
* blongden |
being pedantic |
| 09:51 |
|
trygvis |
yes you are :) |
| 09:51 |
|
blongden |
Almost certainly just doing xml-y things will be of limited use |
| 09:52 |
|
blongden |
The point is that it's perfectly ok :D |
| 09:57 |
|
interop_madness |
the client knows that there is only application/vnd.contoso.mytype+xml and application/vnd.contoso.mytype+json for that particular resource |
| 09:57 |
|
interop_madness |
my thinking was, if the client demands text/xml, it probably means application/vnd.contoso.mytype+xml, so i deliver that |
| 10:02 |
|
blongden |
Yep. Works for me. :) |
| 10:03 |
|
trygvis |
how hard would it be for your clients to request the correct type? |
| 10:03 |
|
trygvis |
I would consider educating them |
| 10:04 |
|
blongden |
I would serve your media type on text/xml. Anything other than text/xml or application/vnd.contoso.mytype+xml i'd return 406. |
| 10:04 |
|
blongden |
"If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response." |
| 10:04 |
|
talios |
Accept IMHO is more a "I'd like this format, over any others you have, i.e. please don't give me JSON" - but you'd still be free to return that custom format, with the Content-Type header properly set, so they can then go "oh, THAT format...." |
| 10:05 |
|
blongden |
Ya. |
| 10:05 |
|
talios |
Personally I'd favour the 406 |
| 10:07 |
|
blongden |
But it's still xml. Why deny it? |
| 10:09 |
|
talios |
so I returned you application/error+xml you'd process it JUST as you would the mytype+xml? |
| 10:09 |
|
talios |
Just having XML or JSON is rather meaningless for an API |
| 10:10 |
|
talios |
if all you're doing is xpath, maybe not |
| 10:10 |
|
talios |
but then you might also be making assumptions over the structure |
| 10:15 |
|
|
_ollie joined #rest |
| 10:23 |
|
|
timg___ joined #rest |
| 10:29 |
|
blongden |
Nope |
| 10:30 |
|
blongden |
If I requested xml I would be expecting to process it as xml |
| 10:30 |
|
blongden |
Both application/error+xml and application/contoso.mytype+xml are xml |
| 10:31 |
|
blongden |
in that case i'd just default to the second one, but if error+xml was returned it wouldn't matter because it's still just xml |
| 10:31 |
|
blongden |
If I was a client that could understand what the semantics of that xml were and requested application/contoso.mytype+xml then that's different. |
| 10:32 |
|
blongden |
Certainly I would not expect a client to request text/xml or application/xml and then process as application/contoso.mytype+xml |
| 10:36 |
|
interop_madness |
if the client knows the semantics, tries to GET a resource with Accept: application/contoso.mytype+xml, but the resource doesn't exist, the server returns http/404 with details in the response body with the representation application/error+xml. the client must at least expect application/error+xml for error status codes. |
| 10:37 |
|
blongden |
Sure |
| 10:38 |
|
blongden |
A generic client (like a browser) would just understand that 404 was not found. A client that understands the error format can do more with it. |
| 10:59 |
|
|
mezod joined #rest |
| 11:02 |
|
|
azr joined #rest |
| 11:03 |
|
|
chthon joined #rest |
| 11:04 |
|
|
_ollie joined #rest |
| 11:12 |
|
|
rosstuck joined #rest |
| 11:34 |
|
|
timg___ joined #rest |
| 14:04 |
|
|
timg___ joined #rest |
| 14:11 |
|
|
fumanchu joined #rest |
| 15:45 |
|
|
timg___ joined #rest |
| 17:08 |
|
|
azr joined #rest |
| 17:17 |
|
|
azr joined #rest |
| 17:24 |
|
|
darrelmiller joined #rest |
| 17:40 |
|
|
azr joined #rest |
| 17:43 |
|
|
azr__ joined #rest |
| 17:55 |
|
|
khayes joined #rest |
| 17:56 |
|
whartung |
here's a puzzle |
| 17:56 |
|
whartung |
simple case |
| 17:56 |
|
whartung |
have a resource |
| 17:56 |
|
whartung |
wnat to DELETE is |
| 17:56 |
|
whartung |
*it |
| 17:57 |
|
whartung |
any ideas on how to specify WHY it was deleted |
| 17:57 |
|
khayes |
I'm trying to define a resource that will contain a list of children, however some of the clients will want to know the number of said children but not want to know the data. Other clients will want to get the children. I'm going back and forth on how to represent this |
| 17:57 |
|
whartung |
DELETE /resource?reason=ISezSo is that icky? |
| 17:57 |
|
khayes |
What's the best way to provide a count of a list within a resource without making a call for that list? |
| 17:58 |
|
whartung |
you can summarize based on teh content type of the requst |
| 17:58 |
|
whartung |
you can have a representation that is just a summary of the actual resource |
| 17:58 |
|
whartung |
app/thing and app/thing-lite |
| 17:59 |
|
asdf` |
eh querystring seems silly; a simple solution would be i guess have a separate resource like 'notes' that you'd create before deleting? but that's super silly |
| 18:00 |
|
whartung |
what we're doing is deleteing a session, and want to know if they user logged out, was timed out, was kicke dout, etc. |
| 18:00 |
|
asdf` |
maybe update the session beforehand with a status=logged_out or something? |
| 18:01 |
|
darrelmiller |
I don't see any issue with the extra query string parameter |
| 18:01 |
|
whartung |
well, if we update that way, we may as well just log them out at that point, right? POST them in to non-existence. |
| 18:02 |
|
whartung |
Hey darrelmiller, how's the world treating you? |
| 18:02 |
|
whartung |
there's a simplicty to it, for sure |
| 18:02 |
|
asdf` |
'practicality beats purity' i suppose |
| 18:03 |
|
darrelmiller |
I'm doing pretty good :-) |
| 18:03 |
|
whartung |
good to hear |
| 18:04 |
|
whartung |
yea we're already deleting the session internally, so it's jsut a status for auditing |
| 18:05 |
|
darrelmiller |
I don't think there is anything impure about query string idea. Conceptually, you are just creating a bunch more resources that can be deleted that then cause the primary resource to be deleted, with the bonus of knowing the reason. REST just requires you to squint at certain design problems. Might look a bit weird but as long as all constraints are intact, all is good. |
| 18:05 |
|
whartung |
yea, I htink it's ok too |
| 18:05 |
|
asdf` |
well creating a whole bunch of resources might be bad for caching i suppose? |
| 18:06 |
|
darrelmiller |
Sure, but the only method they support is DELETE so caching isn't going to help much. It does make it harder to invalidate cached copies of the primary resource though. |
| 18:06 |
|
whartung |
well like I said, this is mostly for auditing the activity, and auditing (from a creation stand point) is a cross cutting concern, out of scope of the resources proper. (i.e. that fact that I audit a GET does not itself make the GET idempotent...) |
| 18:07 |
|
whartung |
yea, does the ? screw up the caches, that's a valid point |
| 18:08 |
|
trygvis |
whartung: I would POST to the resource to delete it |
| 18:08 |
|
saml |
DELETE /resource POST /audit?p=/resource&m=DELETE&why=cause+I+like+boobies |
| 18:09 |
|
darrelmiller |
whartung: Most caches will treat URLs with query string values as distinctly cacheable resources. |
| 18:09 |
|
whartung |
the audit is a side affect saml, I don't want the clients to be in charge of my auditing. |
| 18:10 |
|
saml |
do you want clients to supply the reason for deletion? |
| 18:10 |
|
whartung |
that's what I'm working on |
| 18:10 |
|
whartung |
"why are you closing this session" |
| 18:10 |
|
saml |
what are possible answers? |
| 18:11 |
|
whartung |
I'd certainly lean more towards trygvis POST over a separate first class audit process |
| 18:11 |
|
saml |
sounds like you can provide different links (multiple choice question) |
| 18:11 |
|
whartung |
off the top of my head: user explicitly logged out, session timed out, adminstrative session terminated |
| 18:12 |
|
darrelmiller |
Wow. It's nice to see this channel is still active. |
| 18:12 |
|
sfisque |
#rest never rests :P |
| 18:12 |
|
whartung |
we all linger |
| 18:13 |
|
pdurbin |
it's a nice place |
| 18:13 |
|
saml |
<link rel="logout" href="/session/1"><link rel="timeout" href="/session/1?timeout"> |
| 18:13 |
|
saml |
no it's weird |
| 18:13 |
|
darrelmiller |
khayes: You could use a custom HTTP header and a HEAD request. Or you could use the prefer header to do what whartung was suggesting. |
| 18:13 |
|
whartung |
the link or this place? |
| 18:13 |
|
saml |
link |
| 18:14 |
|
|
timg___ joined #rest |
| 18:14 |
|
saml |
yah usually POST |
| 18:14 |
|
khayes |
darrelmiller, I was literally getting ready to type that very thing. I think that is what I will do |
| 18:14 |
|
khayes |
Thank you |
| 18:14 |
|
sfisque |
except why would a client send a timeout to the servcie endpoint. wouldnt that be handled internally? |
| 18:14 |
|
saml |
is http2 rest? |
| 18:15 |
|
sfisque |
otherwise it's an explicit logout |
| 18:15 |
|
sfisque |
i cant even imagine a case where the client times itself out of an external service call |
| 18:15 |
|
darrelmiller |
saml: You can do REST with http/2 and you can not do REST with http/2 |
| 18:16 |
|
whartung |
well, if you log in to a web site, and then walk away, X minutes later you get "logged out" because the session expires vs just clicking the logout button |
| 18:16 |
|
saml |
wat |
| 18:16 |
|
sfisque |
that's a UX construct. t he session already was gone, regardless whether you click the button or not |
| 18:16 |
|
saml |
i should not do REST with http/2 |
| 18:16 |
|
darrelmiller |
I do believe that http/2 makes it easier to do REST properly. |
| 18:16 |
|
darrelmiller |
saml: Why? |
| 18:17 |
|
whartung |
but it's an important distinction to us. |
| 18:17 |
|
whartung |
yea, the session doesn't care, but WE care |
| 18:17 |
|
saml |
cause i don't know http/2.i should learn it first |
| 18:17 |
|
sfisque |
we (client) or we (service)? |
| 18:17 |
|
darrelmiller |
haha. Well, that kinda goes for everything, no? |
| 18:17 |
|
whartung |
We me and my people who ask me silly questions |
| 18:17 |
|
saml |
use websocket for login. if connection is closed, you're logged out |
| 18:18 |
|
whartung |
We, the CBL's that manage our systems |
| 18:18 |
|
sfisque |
aye but i do not think timeout is a REST concept. that's deeper and has no bearing whether its rest, corba, or an RPC call |
| 18:18 |
|
sfisque |
it's internal (clocking and session mmgmt) |
| 18:18 |
|
whartung |
no, it's not a rest concept at all, but this is an authentication service designed to create and manage authentcation sessions for other applications. |
| 18:18 |
|
whartung |
so it IS a "Session Concept" |
| 18:19 |
|
whartung |
which is the resourece we're modeling |
| 18:19 |
|
sfisque |
ah, so you're building a service <-> service |
| 18:19 |
|
sfisque |
now i see |
| 18:20 |
|
sfisque |
in that case you get to choose if it's an attribute of a session or a durable object (it's own uri component). it's == the choices of logout, timeout, forceout, etc. |
| 18:21 |
|
sfisque |
you get to choose if you want session/X/logout_type or session/X (header timeout_type : value) |
| 18:21 |
|
sfisque |
or session/X?type |
| 18:21 |
|
sfisque |
how do you want to skin the cat :-D |
| 18:22 |
|
whartung |
Ways to skin a cat #42: Crazy glue and a toothbrush |
| 18:23 |
|
sfisque |
ROFL |
| 18:23 |
|
sfisque |
my vote would be treat it as an attribute but send it as a header bit, so that you don't "offend" caching :P |
| 18:25 |
|
whartung |
I like the header idea |
| 18:26 |
|
whartung |
I think I finally managed to grok the roles in OAuth today -- I always hated their vocabulary... |
| 18:29 |
|
darrelmiller |
+1 to Oauth hatred. |
| 18:35 |
|
whartung |
So, I want to get some chips from the storage room. Cheryl has the key to the room, but needs a note from Gary to let me have it. So I go to Gary, get the note, give it to Cheryl, then I take the key, open the room and get my chips. Gary is the Resrouce Owner, Cheryl is the Authz server, I am the Client, and the storage room is the Resource server. |
| 18:36 |
|
whartung |
that's just so much easier for me to grok than there photo example |
| 18:36 |
|
whartung |
"That OAuth spec uses different words for everything" -- S. Martin |
| 18:44 |
|
darrelmiller |
It is the other player that gets me. You say you are the client, but in many situations there is the "client application" that has credentials and there is the human user using the client application that has a different set of credentials. |
| 18:44 |
|
whartung |
yea |
| 18:45 |
|
darrelmiller |
And in every situation other than a web app client, there is no way to secure the client credentials.... |
| 18:45 |
|
darrelmiller |
grrrrrr. |
| 18:51 |
|
whartung |
the user credentials are unspecified between Client and the Resource Owner |
| 18:52 |
|
darrelmiller |
Right. At that point it's just AuthZ creds. |
| 18:54 |
|
whartung |
I don't like how they conflate the Authz server for createing the Auth Grant, and then creating the Access_token |
| 18:54 |
|
whartung |
in their diagrams |
| 18:58 |
|
darrelmiller |
I just typed the OAuth RFC # from memory. That's how sad I am. |
| 18:58 |
|
whartung |
I has a sad for you |
| 18:59 |
|
whartung |
Mind, I have SAML payloads tatooed on my body…somewhere…I think…feels like it. I mean, I should…or something. |
| 19:00 |
|
saml |
i'm tatooed on girls shoulder |
| 19:01 |
|
darrelmiller |
The diag here http://tools.ietf.org/html/rfc6749#section-1.2 shows the auth grant coming from the resource owner (which is bizarre in itself) and then the token coming from the Authz server. |
| 19:01 |
|
|
azr joined #rest |
| 19:01 |
|
whartung |
yea, but then look at http://tools.ietf.org/html/rfc6749#section-4.1 |
| 19:04 |
|
darrelmiller |
Yeah, it would be much better if they treated them as distinct resources and if they happen to be deployed to the same server then so be it. |
| 19:04 |
|
whartung |
si |
| 19:04 |
|
whartung |
I. MUST. FEED!… lunch beckons, I must stalk co-workers. |
| 19:05 |
|
darrelmiller |
I also think the IETF should get past the ASCII constraint. What year are we? |
| 19:05 |
|
whartung |
IETF can't afford the bandwidth to host images. |
| 19:06 |
|
darrelmiller |
SVG :-) |
| 19:06 |
|
whartung |
:) |
| 19:08 |
|
whartung |
all good RFC use an ASR-33 for page layout and are printed on paper towels out of a BAUDOT TTY |
| 19:08 |
|
darrelmiller |
Hey whartung, you're old! |
| 20:02 |
|
|
azr joined #rest |
| 20:02 |
|
|
azr joined #rest |
| 20:11 |
|
|
igitoor joined #rest |
| 20:17 |
|
whartung |
wait, what?That |
| 20:17 |
|
whartung |
That's not current tech?? |
| 20:21 |
|
darrelmiller |
Even IANA have adopted XHTML. |
| 20:30 |
|
|
igitoor joined #rest |
| 20:37 |
|
|
Coldblackice joined #rest |
| 21:02 |
|
|
zama joined #rest |
| 21:16 |
|
|
fuzzyhorns joined #rest |
| 21:24 |
|
|
talios joined #rest |
| 22:05 |
|
|
azr joined #rest |
| 22:57 |
|
|
blahdeblah joined #rest |
| 23:11 |
|
|
azr joined #rest |
| 23:46 |
|
|
fuzzyhorns joined #rest |
