| Time |
S |
Nick |
Message |
| 01:43 |
|
|
ekroon joined #rest |
| 02:30 |
|
|
alxbl joined #rest |
| 03:18 |
|
|
fuzzyhorns joined #rest |
| 04:01 |
|
|
vanHoesel joined #rest |
| 04:31 |
|
|
baweaver joined #rest |
| 06:00 |
|
|
fumanchu_ joined #rest |
| 06:10 |
|
|
Left_Turn joined #rest |
| 07:14 |
|
|
rosstuck joined #rest |
| 08:13 |
|
|
quimrstorres joined #rest |
| 08:15 |
|
|
quimrsto_ joined #rest |
| 09:22 |
|
|
quimrstorres joined #rest |
| 09:38 |
|
|
graste joined #rest |
| 10:56 |
|
|
vanHoesel joined #rest |
| 11:43 |
|
|
sfisque joined #rest |
| 12:06 |
|
|
vanHoesel joined #rest |
| 13:19 |
|
|
quimrstorres joined #rest |
| 13:29 |
|
|
kevinswiber joined #rest |
| 13:32 |
|
|
nkoza joined #rest |
| 13:50 |
|
|
fuzzyhorns joined #rest |
| 14:22 |
|
|
foist joined #rest |
| 14:27 |
|
|
kevinswiber joined #rest |
| 14:43 |
|
|
fuzzyhor_ joined #rest |
| 15:40 |
|
|
baweaver joined #rest |
| 16:34 |
|
|
kevinswiber joined #rest |
| 17:43 |
|
|
kevinswiber joined #rest |
| 18:15 |
|
|
quimrstorres joined #rest |
| 18:30 |
|
|
vanHoesel joined #rest |
| 18:34 |
|
|
baweaver joined #rest |
| 18:38 |
|
|
Rotaerk joined #rest |
| 18:44 |
|
Rotaerk |
given the rules of a RESTful service, it seems like if the client needs to store the identifier for a resource... it should *not* be the URI |
| 18:44 |
|
Rotaerk |
"A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace." |
| 18:44 |
|
Rotaerk |
so does that mean the service should have a separate identification scheme for entities, and a way of dynamically mapping these identifiers to the corresponding URI |
| 18:45 |
|
Rotaerk |
these identifiers would be fixed, and not tied to the topology of the resource hierarchy |
| 18:45 |
|
trygvis |
the URI is a very good identifier to store |
| 18:45 |
|
Rotaerk |
but that seems to violate the REST principle |
| 18:45 |
|
Rotaerk |
above |
| 18:46 |
|
trygvis |
they have the freedom to have their own hierarchy, but they can't change it |
| 18:47 |
|
Rotaerk |
no it says the freedom to *control* the hierarchy; taking HATEOAS into account, it suggests that it can change the hierarchy all it wants |
| 18:47 |
|
Rotaerk |
but that doesn't affect the client because they navigate through the links provided |
| 18:47 |
|
Rotaerk |
but it *does* break things if the client needs to persist some kind of entity reference |
| 18:48 |
|
Rotaerk |
HATEOAS seems to suggest that all URIs apart from the root one are ephemeral |
| 18:48 |
|
Rotaerk |
I'm just not really clear on how to resolve that |
| 18:49 |
|
trygvis |
well, they *should*be useful at least for as long as the resource they where referenced from is cacheable |
| 18:49 |
|
trygvis |
but they really are supposed to be picked up again at any time |
| 18:50 |
|
trygvis |
an alternative is to use URNs if you want to force the client to have a client-side resolver |
| 18:50 |
|
trygvis |
but I would hate your API :) |
| 18:51 |
|
Rotaerk |
I was thinking maybe if I had, say, a database of people, the URL would be: http://.../api/persons/123456789 |
| 18:52 |
|
Rotaerk |
but that's just the *current location* of the person entity |
| 18:52 |
|
Rotaerk |
the permanent ID could be ... person:123456789 |
| 18:52 |
|
Rotaerk |
(another URI) |
| 18:52 |
|
Rotaerk |
and then you could request the current URL for person:123456789 from the API, and it'd give you http://.../api/persons/123456789 |
| 18:53 |
|
trygvis |
right, that's is the URN way |
| 18:53 |
|
Rotaerk |
k |
| 18:54 |
|
trygvis |
an URI is both URN and an URL, a URL is a specific location which can be accessed and URN *has* to be resolved to a location before it can be accessed |
| 18:55 |
|
Rotaerk |
according to wikipedia, there's only URI now |
| 18:55 |
|
trygvis |
uh? |
| 18:55 |
|
Rotaerk |
that URL is an informal thing, and URN is ... replaced by URIs |
| 18:55 |
|
trygvis |
I wouldn't trust wikipedia when it comes to technical content |
| 18:56 |
|
trygvis |
but the principle still applies |
| 18:56 |
|
pdurbin |
there is only one REST wiki to trust |
| 18:56 |
|
trygvis |
;) |
| 18:56 |
|
trygvis |
Rotaerk: but I wouldn't sweat it and just assume that you can always go back to the old location |
| 18:56 |
|
Rotaerk |
"The URN concept was formally defined in 1997, and in 2005, to avoid confusion with the term "URL", the use of the terms URL and URN has been deprecated in favor of the less-restrictive "URI" (illustrated)." |
| 18:56 |
|
trygvis |
without it the whole stateless-ness thing won't work |
| 18:57 |
|
trygvis |
[citation needed] |
| 18:57 |
|
Rotaerk |
heh |
| 18:58 |
|
Rotaerk |
well "assuming you can always go back to the old location" seems to be a violation of REST :\ |
| 18:58 |
|
sfisque |
that is a good point. if ALL URI's are ephemeral that intrinsically assumes state |
| 18:58 |
|
Rotaerk |
even if it's not something that changes frequently |
| 18:58 |
|
Rotaerk |
how does that imply state? |
| 18:58 |
|
sfisque |
bah, i was referencing what trygvis said |
| 18:59 |
|
Rotaerk |
yes I got that :P |
| 18:59 |
|
sfisque |
your comment slipped in between |
| 18:59 |
|
sfisque |
if an object's "location" can suddenly change at any given point, then it's location is stateful |
| 18:59 |
|
|
graste joined #rest |
| 18:59 |
|
sfisque |
by definition |
| 19:00 |
|
Rotaerk |
REST doesn't imply lack of state, everywhere |
| 19:00 |
|
Rotaerk |
it implies that the representation doesn't depend on any contextual state for it to make sense |
| 19:00 |
|
Rotaerk |
(the representation is complete) |
| 19:00 |
|
Rotaerk |
there's naturally going to be state in the resources themselves |
| 19:00 |
|
Rotaerk |
when you POST/PUT, you're changing state |
| 19:01 |
|
Rotaerk |
well, *might* be changing state |
| 19:01 |
|
sfisque |
but now we're talking about state being tied to location |
| 19:01 |
|
sfisque |
not just representatin |
| 19:01 |
|
sfisque |
i don't see that being reconcilable without hand-waving |
| 19:02 |
|
trygvis |
Rotaerk: if all URLs are ephemeral, how can you even resolve something? after is has been resolved, may be gone |
| 19:02 |
|
Rotaerk |
I suppose what's ephemeral is the linkage between resources... not necessarily the resources themselves, and their locations |
| 19:02 |
|
Rotaerk |
so the root might change to no longer *point* to a resource, but the resource itself is still resolvable if you go to it directly |
| 19:03 |
|
Rotaerk |
(until you retire it) |
| 19:03 |
|
Rotaerk |
it just seems to me though that it's overly restrictive for entity IDs to be the full URL |
| 19:03 |
|
trygvis |
right, so doesn't that mean that http://.../api/persons/123456789 is always available |
| 19:04 |
|
trygvis |
it may be, but it's the most useful thing you have unless you start looking into the hypermedia |
| 19:04 |
|
sfisque |
how is it "restrictive"? i don't see how that follows |
| 19:04 |
|
trygvis |
atom has it's own definition of ID |
| 19:04 |
|
sfisque |
it's no more restrictive than saying x = 2342344234234 |
| 19:05 |
|
sfisque |
and ID is just an opaque identifier |
| 19:05 |
|
trygvis |
sfisque: not if you have to go through a resolver |
| 19:05 |
|
sfisque |
aye |
| 19:05 |
|
trygvis |
atom does it that way because two atom document may include the same entry |
| 19:06 |
|
trygvis |
other hypermedias may have similar techniques, but modern hypermedias use the URLs as identifiers |
| 19:06 |
|
trygvis |
like HAL and C+J |
| 19:06 |
|
Rotaerk |
trygvis: well, the way it's restrictive is that the identity of the *entity* is dependent on the site itself remaining in the same place |
| 19:06 |
|
trygvis |
Rotaerk: I think the alternative is to let the server to the resolution with a redirect |
| 19:06 |
|
Rotaerk |
if the IDs are *relative*, then the site can move without breaking the IDs |
| 19:06 |
|
trygvis |
so /api/resolve/person=123 would redirect you to /api/person/123 or http://s3.amazon.com/234782364872346 |
| 19:07 |
|
trygvis |
the URL is opaque, you can't fiddle with it |
| 19:07 |
|
sfisque |
trygvis that makes more sense, and captures the intent of that directive |
| 19:07 |
|
sfisque |
the server can always send a "Resource Moved" |
| 19:08 |
|
sfisque |
or similar |
| 19:08 |
|
sfisque |
depending on the details |
| 19:08 |
|
trygvis |
yes, and it say if it is a temporary or permanent move too |
| 19:08 |
|
trygvis |
again, you can always create other ways to implement your way, but it will work against The Web |
| 19:10 |
|
trygvis |
http://tools.ietf.org/html/rfc3986#section-1.1.3 |
| 19:10 |
|
trygvis |
^ ref the urn/uri/url |
| 19:10 |
|
Rotaerk |
I read through the Roy Fielding paper on REST, and it seemed to make it clear that "resource" is just a node bearing semantics and doesn't have to uniquely refer to an entity |
| 19:10 |
|
Rotaerk |
multiple resources can point to the same entity |
| 19:11 |
|
trygvis |
they can, but then you loose much of the usefulness of the current implementation |
| 19:11 |
|
sfisque |
yes. afaik a URL/URI is a "unique location" but not has never been defined as a "unique entity" |
| 19:11 |
|
trygvis |
I guess the problem is that there isn't any other definition of identity so people just use the URI |
| 19:12 |
|
sfisque |
but, as mentioned, the more indirection your api provides, the muddier it will be to your implementers/clients |
| 19:12 |
|
sfisque |
then you get into resolution, redirection, etc. |
| 19:12 |
|
Rotaerk |
it means that if multiple URIs can refer to the same entity, and the URI is the ID, then that means an entity can have multiple IDs simultaneously |
| 19:12 |
|
trygvis |
amazon does what you seem to suggest Rotaerk, all users and other objects are URNs which is resolved through their API |
| 19:12 |
|
sfisque |
that is not irreconcilable. i have many id's across many systems |
| 19:13 |
|
sfisque |
in one system, i am a SSI, in another i am an email addy, in another i am some generated serial number, etc. |
| 19:13 |
|
trygvis |
sfisque: but those user accounts are not the same resource |
| 19:13 |
|
trygvis |
you can't exchange one for the other |
| 19:15 |
|
Rotaerk |
on a different note, something about HTTP that I'm vague on is media types |
| 19:15 |
|
Rotaerk |
are they supposed to represent just the encoding of the data, or are they supposed to represent a *view* of the data |
| 19:15 |
|
Rotaerk |
as in, different media types can report different aspects of the same resource |
| 19:16 |
|
Rotaerk |
so the accepted media types are representative of arbitrary functions applicable to the resource |
| 19:16 |
|
Rotaerk |
json is just a simple-stupid "encode the entire resource as JSON" |
| 19:17 |
|
trygvis |
json is almost as dumb as you get it |
| 19:17 |
|
trygvis |
. o O (but still people love it) |
| 19:17 |
|
Rotaerk |
but would, say "biography", be a valid media type for a "person" resource, where the resulting representation is a log of the person's life |
| 19:17 |
|
Rotaerk |
and then "medical history" media type, might list their medical history |
| 19:17 |
|
Rotaerk |
etc |
| 19:17 |
|
* sfisque |
personally dislikes json |
| 19:18 |
|
trygvis |
Rotaerk: that is one way to do it, but it's not very useful |
| 19:19 |
|
trygvis |
a more useful approach would have application/log which contains entries of type=life-log and type=medical-visit |
| 19:20 |
|
Rotaerk |
hmm but when the client wants to request the medical visit only, how do they do that? |
| 19:20 |
|
Rotaerk |
I thought the media type was the mechanism for content negotiation |
| 19:21 |
|
trygvis |
yes, but the content type is "log". the application tells you what kind of data that is available |
| 19:21 |
|
trygvis |
so you could have a person resource with links, and your app would follow the "log life" rel or "log medical" rel |
| 19:22 |
|
trygvis |
so the person has pointers to the other resources |
| 19:24 |
|
|
vanHoesel joined #rest |
| 19:24 |
|
Rotaerk |
hmm what about this then: supporting a "log" media type and an html media type |
| 19:25 |
|
Rotaerk |
so if you request the log media type, you get raw data, for use by software |
| 19:25 |
|
Rotaerk |
and if you request the html media type, you get the same data formatted for presentation |
| 19:25 |
|
trygvis |
some people like it that way |
| 19:26 |
|
trygvis |
but it turns out to be lot of work for those who write the server, so people instead create clients for HAL and C+J |
| 19:26 |
|
trygvis |
so you can browse the "machine" media type directly |
| 19:26 |
|
Rotaerk |
it seems like HTTP has some... redundant features |
| 19:26 |
|
Rotaerk |
don't see anything you can do with media type that can't just as easily be done by just creating two separate resources |
| 19:27 |
|
Rotaerk |
well, N separate resources |
| 19:27 |
|
trygvis |
it's choice. and it makes it easier to move stuff later on |
| 19:29 |
|
trygvis |
but yeah, I doubt content negotiation is the most used feature out there |
| 19:31 |
|
|
nkoza joined #rest |
| 19:32 |
|
Rotaerk |
I guess one problem with thinking of media types as, essentially, arbitrary views/methods of the resource is... |
| 19:32 |
|
|
blahdeblah_ joined #rest |
| 19:32 |
|
Rotaerk |
you can't exactly *link* to one specific media type of the resource |
| 19:32 |
|
trygvis |
right. and that is a feature :) |
| 19:32 |
|
Rotaerk |
so the functionality wouldn't be discoverable via HATEOAS |
| 19:33 |
|
Rotaerk |
then again... |
| 19:33 |
|
Rotaerk |
*functionality* isn't discoverable anyway... the client needs to know how to use it anyway |
| 19:33 |
|
trygvis |
you request what you support, the server respond with the best it can offer you |
| 19:33 |
|
Rotaerk |
just not necessarily *where* the resources are |
| 19:34 |
|
|
vanHoesel joined #rest |
| 19:35 |
|
Rotaerk |
can't actually think of anything wrong with using media types for that, then, apart from that it's not the popular way to do it |
| 19:35 |
|
trygvis |
for what? |
| 19:35 |
|
|
kevinswiber joined #rest |
| 19:36 |
|
Rotaerk |
media type = transformation/view of the resource |
| 19:36 |
|
Rotaerk |
not merely an encoding |
| 19:36 |
|
Rotaerk |
so I could do a GET with the media type being "count" from the persons resource, to get back the number of persons |
| 19:37 |
|
Rotaerk |
"list" to get a list of them |
| 19:37 |
|
Rotaerk |
etc |
| 19:37 |
|
trygvis |
then you're certainly working against the system |
| 19:37 |
|
Rotaerk |
is it working against the HTTP standard, or the concept of REST, or just the conventional application of them? |
| 19:38 |
|
trygvis |
all of the above |
| 19:38 |
|
Rotaerk |
hmm how is it an abuse as far as the standard is concerned |
| 19:39 |
|
trygvis |
well, it would work but you're not following its intent |
| 19:39 |
|
trygvis |
at least as long as you use valid media types (has to be "major/minor") |
| 19:40 |
|
|
Coldblackice joined #rest |
| 19:40 |
|
Rotaerk |
wait, media types have to be a global standard? |
| 19:41 |
|
trygvis |
http://www.iana.org/assignments/media-types/media-types.xhtml |
| 19:41 |
|
trygvis |
^ that's all of the registered ones |
| 19:41 |
|
Rotaerk |
hmm yea they look mostly like file formats |
| 19:42 |
|
trygvis |
it's a list of media types, not hypermedias |
| 19:43 |
|
sfisque |
yah two types generally speaking, file format (jpeg vs. pdf vs excel, etc.) and content format (binary vs. text vs. image etc.) |
| 19:44 |
|
Rotaerk |
k |
| 19:45 |
|
Rotaerk |
hmm instead, is POST a valid means of requesting data from the resource, given parameters? |
| 19:45 |
|
Rotaerk |
I mean, depending on the server to implement it this way |
| 19:45 |
|
trygvis |
only if the hypermedia told you how to create the post |
| 19:45 |
|
Rotaerk |
but, would it be an abuse to make a resource handle POSTs as essentially parameterized GETs |
| 19:45 |
|
Rotaerk |
where the parameter is in the body of the request |
| 19:46 |
|
trygvis |
yes, you would loose the caching feature |
| 19:46 |
|
Rotaerk |
hmm URL parameters, though, are insufficient for non-trivial parameterization |
| 19:46 |
|
trygvis |
some applications support POST to send big queries, but return an URL the client has to GET to see the result |
| 19:46 |
|
Rotaerk |
ah, interesting |
| 19:46 |
|
trygvis |
that depends on your application |
| 19:47 |
|
trygvis |
but if you have a big query it might only be overhead if there will only be one GET later on |
| 19:48 |
|
trygvis |
not really depending on whether the query is big, but if it is likely that it will be fetched again soon |
| 19:48 |
|
|
vanHoesel joined #rest |
| 19:49 |
|
Rotaerk |
so if it's something that's likely to be one-off, creating a new URL to GET from is not practically any better than just returning the the results in the response from the POST |
| 19:49 |
|
Rotaerk |
but if it's something that may be re-run, it's better to do it via GET for the sake of caching |
| 19:50 |
|
trygvis |
yep |
| 19:51 |
|
trygvis |
any good HTTP client handle both directly so the server can even decide on a per-request basis |
| 19:51 |
|
trygvis |
HTTP <3 |
| 19:51 |
|
Rotaerk |
heh |
| 19:52 |
|
Rotaerk |
wait, what do you mean "any good HTTP client [will] handle both directly"? |
| 19:52 |
|
Rotaerk |
isn't the client generally custom implemented with the service in mind |
| 19:53 |
|
Rotaerk |
and so it would be tailored to whichever the service chooses |
| 19:53 |
|
trygvis |
you usually have two layers, the generic HTTP client and the hypermedia-specific client |
| 19:53 |
|
Rotaerk |
oh |
| 19:53 |
|
trygvis |
that is kinda the whole point of specifying so much, to make it possible to reuse both semantics and code |
| 19:54 |
|
trygvis |
for the query example, if the POST returns the body it can just give it to to the hypermedia layer, if it returns a redirect it will follow the GET and send that response to the next level |
| 19:54 |
|
Rotaerk |
is the "HTTP client" layer something built in to ASP.NET, something built into ASP.NET Web API, or something that regardless of what framework you use, you would generally implement, yourself? |
| 19:54 |
|
Rotaerk |
err wait no, that's server... |
| 19:54 |
|
Rotaerk |
haven't looked into HTTP client libraries/frameworks |
| 19:54 |
|
trygvis |
I don't know how people do it in the .net world |
| 19:55 |
|
Rotaerk |
k |
| 19:55 |
|
trygvis |
but for java there are several good clients and I know there are for other platforms too |
| 19:57 |
|
Rotaerk |
well, thanks for the discussion and advice |
| 19:58 |
|
Rotaerk |
think that's all of my questions/concerns for now |
| 19:58 |
|
trygvis |
:) |
| 20:05 |
|
Rotaerk |
well... actually.. :P |
| 20:05 |
|
Rotaerk |
"A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entir |
| 20:05 |
|
Rotaerk |
ely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types)." |
| 20:06 |
|
sfisque |
aye, that would apply to the x- media types. any media type starting with "x-" is considered properitary and "context defined" |
| 20:06 |
|
sfisque |
application/x-my-media-type |
| 20:06 |
|
sfisque |
text/x-my-text-file-format |
| 20:07 |
|
Rotaerk |
well that seems to *imply* the use of media types I suggested earlier: every desired transform on a resource (such as getting the count of persons or a list of the existing persons) would be a media type |
| 20:07 |
|
Rotaerk |
those are like "methods" of the resource |
| 20:08 |
|
sfisque |
of course, but most are already defined. for a simple plain text list text/ascii is a valid return content type |
| 20:10 |
|
trygvis |
sfisque: you mean text/plain :) |
| 20:10 |
|
sfisque |
media types (from a http standpoint) are defined around the "what" and not the "how" or "why" of a resource. binary/octet-stream defines a binary stream, regardless of whether it is a BER block, an executable library, or such |
| 20:10 |
|
sfisque |
yes |
| 20:11 |
|
sfisque |
but there ARE refinements of those generic flavors (like image/tiff |
| 20:11 |
|
sfisque |
) |
| 20:11 |
|
Rotaerk |
hmm, if I have an api which supports persons and places, and I use HATEOAS, the client would do a GET from the "api" node, expecting a representation that will provide it a link to the "persons" resource and to the "places" resource |
| 20:11 |
|
sfisque |
and you can always offer up your own x-blah refinements for cases to capture your resources, but defining that media type around "usage" rather than "what" is a possible unnecessary rabbit-hole i feel |
| 20:12 |
|
Rotaerk |
so the api node would need to have a media type... a format that provides a persons and a places link |
| 20:12 |
|
sfisque |
i cannot comment, my understanding of hateoas is still developing |
| 20:12 |
|
Rotaerk |
so that the client, when implementing this media type, knows how to parse-out the two links with an understanding of which is which |
| 20:13 |
|
sfisque |
depends. |
| 20:13 |
|
Rotaerk |
if the media type is merely plain-text, there the only processing rules are to dump it into a string |
| 20:13 |
|
trygvis |
the "link relations" stuff comes in when you want to understand which is which |
| 20:13 |
|
sfisque |
if the payload is delivered in a "standard" manner, the parsing happens natively. |
| 20:14 |
|
sfisque |
if i send you a BER block, you can parse out each bit according to BER extraction rules |
| 20:14 |
|
sfisque |
if i send you csv, you need csv parsing |
| 20:14 |
|
sfisque |
if i send you links to an LDAP server, you need to follow those |
| 20:15 |
|
Rotaerk |
right, so if your media type is something generic like that, the media type itself will not promise anything along the lines of... having a persons resource link and a places link |
| 20:15 |
|
sfisque |
minimally, i guess so |
| 20:15 |
|
Rotaerk |
so to parse them out, your client must have some knowledge about a format *on top of* that generic format |
| 20:15 |
|
Rotaerk |
e.g. an XML schema on top of the generic format of "xml" |
| 20:15 |
|
sfisque |
you always have to have that |
| 20:15 |
|
trygvis |
usually you have http client -> hypermedia client -> application client |
| 20:16 |
|
Rotaerk |
but that's what that rest principle seems to be *against* |
| 20:16 |
|
sfisque |
unless you attempt the "opendoc" manner and ship the execution with the data |
| 20:16 |
|
Rotaerk |
"Failure here implies that out-of-band information is driving interaction instead of hypertext." |
| 20:16 |
|
trygvis |
so if I have a collection+json client I can say "give me the URL if this item with rel='foo bar'" |
| 20:16 |
|
Rotaerk |
having some higher-level format on top of but not inherent to the media type qualifies as "out of band information" |
| 20:16 |
|
trygvis |
you always need to code your application, that is kind of obvious |
| 20:17 |
|
sfisque |
don't mistake "out of band information" with execution. just because you need to load a tiff rendering lib does not mean REST is broken just because the server shipped you a TIFF file |
| 20:17 |
|
sfisque |
you still need to know (at the client) what to do with that payload |
| 20:17 |
|
sfisque |
unless, again, you attempt to ship the impl with the data (a la opendoc) |
| 20:18 |
|
sfisque |
and yes, i realize i'm dating myself with references to opendoc :P |
| 20:18 |
|
Rotaerk |
a tiff rendering lib would be one way of "processing" the tiff, but it doesn't assume a higher level format aside from the media type "tiff" |
| 20:19 |
|
Rotaerk |
so if the media type was "csv", the client should do nothing about parsing it beyond having strings separated by commas |
| 20:19 |
|
sfisque |
untrue. the only difference here is standardization |
| 20:20 |
|
sfisque |
when a tiff block is encountered there is a standard way to interpret it while cruising through a tiff file. interpreting a "phone_num" field in your file, is proprietary, and the client either has to know how to interpret that OR you need to ship the interpreter with the data |
| 20:20 |
|
sfisque |
UNLESS you adopt something standard, like x509 or similar |
| 20:20 |
|
sfisque |
then your fields are semantically defined for you |
| 20:21 |
|
sfisque |
but lacking a "standard" for some context, you are pressed with either letting the client do its own interpretation (aka, the dev has to RTFM on your site) or you ship the impl to them |
| 20:22 |
|
sfisque |
which isnt terrible |
| 20:22 |
|
Rotaerk |
I'm not saying the client shouldn't do interpretation; it must |
| 20:22 |
|
sfisque |
right |
| 20:22 |
|
sfisque |
but don't fight so hard for "control". if they interpret incorrectly, its not your fault. |
| 20:23 |
|
sfisque |
you can give them the "tools" but they can still use a shoe as a hammer |
| 20:25 |
|
Rotaerk |
I'm just saying that it seems like that third principle is saying that there should not be semantics pertinent to processing that lie outside the media type |
| 20:25 |
|
Rotaerk |
so for example, if your client needs to look for specific fields in your CSV file.. |
| 20:26 |
|
Rotaerk |
then its media type shouldn't be CSV, but something more specific |
| 20:26 |
|
sfisque |
it depends |
| 20:26 |
|
Rotaerk |
so then the client-side interpretation of the data is nothing more than the client handling that media type |
| 20:26 |
|
sfisque |
media types are for "handling", not interpreting |
| 20:27 |
|
Rotaerk |
vague :P |
| 20:27 |
|
sfisque |
the fact that i can handle a tiff does not mean i got the right one when it arrives. that requires rules |
| 20:27 |
|
sfisque |
and rules == human or some heuristic algorithm |
| 20:27 |
|
sfisque |
or engine |
| 20:28 |
|
Rotaerk |
sure, but i think the distinction here is validity versus correctness |
| 20:28 |
|
Rotaerk |
if your client expects a TIFF file, then you can receive a wrong TIFF file, but it's still valid |
| 20:28 |
|
sfisque |
right. so if i get csv and the media type is csv, then 200 and all is good |
| 20:28 |
|
sfisque |
regardless of whether the phone number is in slot 3 , slot 8, or slot 12 |
| 20:29 |
|
sfisque |
that's interpretation and requires more than rest dictates |
| 20:29 |
|
sfisque |
at least as far as i understand rest |
| 20:29 |
|
Rotaerk |
if the media type is "csv", then that means any csv is valid; but if the client requires a certain set of fields within the CSV... then not any CSV is valid |
| 20:30 |
|
Rotaerk |
not just any * |
| 20:30 |
|
Rotaerk |
so this disparity is resolved by making the media type be "csv-meeting-my-constraints" |
| 20:30 |
|
sfisque |
now if you wanted to provide links to some form of schema in your hierarchy for validation, then that is part of your api |
| 20:30 |
|
sfisque |
x-csv-meeting-my-constraints |
| 20:30 |
|
Rotaerk |
right |
| 20:30 |
|
sfisque |
OR |
| 20:31 |
|
sfisque |
csv and you publish some validation rules/schema/impl-lib at a different node in your tree and expose it for clients to DL and bind |
| 20:31 |
|
sfisque |
you could have a drools lib at some other node, and set of drools configs for validating endpoint request results |
| 20:31 |
|
Rotaerk |
that's certainly possible; I'm just saying it seems like that violates that rule #3 |
| 20:33 |
|
sfisque |
not sure how? |
| 20:33 |
|
sfisque |
**not sure how |
| 20:34 |
|
|
kevinswiber joined #rest |
| 20:36 |
|
Rotaerk |
hmm I may be misinterpreting "Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type" |
| 20:37 |
|
Rotaerk |
since this is REST and not HTTP, I'm not sure whether "methods" refers to GET/POST/PUT/etc |
| 20:37 |
|
Rotaerk |
or if it refers to something more generic |
| 20:40 |
|
Rotaerk |
though this is from rule #6 and seems to be more obviously violated by that: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API)." |
| 20:41 |
|
Rotaerk |
the client should know nothing more about the service than the root URI, and the media types. if they are assuming certain formats *on top of* the media types, then ... that is a violation |
| 20:43 |
|
trygvis |
if you follow that interpretation there really isn't much you can do with anything |
| 20:43 |
|
sfisque |
as i understand it, if i specify image/tiff i should be delivering data that parses properly as a tiff image. outside of that, you're working in the business logic arena and outside of what rest requires |
| 20:43 |
|
Rotaerk |
trygvis: hmm why not? |
| 20:44 |
|
trygvis |
what could you do? |
| 20:44 |
|
sfisque |
gotta bounce, but loved the discussion. thx :-) |
| 20:44 |
|
sfisque |
be well all |
| 20:44 |
|
* sfisque |
goes afk |
| 20:45 |
|
whartung |
yea, that's complete BS Rotaerk |
| 20:45 |
|
trygvis |
you always have an application/intent on top of the hypermedia, if not you really can't do anything |
| 20:45 |
|
whartung |
utter, total, fly encrusted doody |
| 20:45 |
|
Rotaerk |
whartung: the rest principle #6 is BS? o_O |
| 20:45 |
|
Rotaerk |
rule * |
| 20:45 |
|
whartung |
No, the idea that there's no such thing as external documentation. |
| 20:46 |
|
whartung |
that the service is do all be all, and that with just an endpoint, all is elightenment |
| 20:46 |
|
Rotaerk |
whartung: that was never said |
| 20:46 |
|
Rotaerk |
there is external documentation, but all it describes is how to process the media types |
| 20:46 |
|
whartung |
nope |
| 20:46 |
|
whartung |
that's not enough |
| 20:46 |
|
Rotaerk |
that's what #6 seems to say |
| 20:47 |
|
Rotaerk |
I can imagine how that would be sufficient |
| 20:47 |
|
Rotaerk |
trygvis: hmm it might be easier if you suggest something that you *can't* do? |
| 20:47 |
|
whartung |
the media type documentation tells you the semantics of the media type. However, the semantics of the media type are NOT the semantics of the application. The media types RARELY have ANYTHING TO DO with the application -- thems completely different. |
| 20:49 |
|
Rotaerk |
whartung: the whole point of a media type is to provide semantics to data, isn't it? why not provide API-specific semantics with application-specific media types? |
| 20:49 |
|
Rotaerk |
API-specific media types * |
| 20:50 |
|
Rotaerk |
trygvis: I mean, I can't tihnk of what couldn't be done with *just* an entry point, and API-specific media type definitions |
| 20:50 |
|
whartung |
because there's no reason for application specific media types. They're unnecessary. Media type is simply a mechanism for creating REPRESENTATIONS of a resource. |
| 20:51 |
|
Rotaerk |
whartung: but the representation of, say, an API which supports persons and places, is a format that provides a link to the persons resource, and a format that provides a link to the places resource |
| 20:51 |
|
Rotaerk |
a representation * |
| 20:51 |
|
whartung |
a key tenet of REST is the use of COMMON media types in order to encourage "serendipitous reuse" |
| 20:52 |
|
Rotaerk |
"A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state..." |
| 20:52 |
|
Rotaerk |
seems to contradict that... |
| 20:53 |
|
Rotaerk |
seem to be saying that you should be defining media types |
| 20:53 |
|
Rotaerk |
also I don't see "use of common media types" in these fielding rules of REST |
| 20:55 |
|
whartung |
"REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." |
| 20:58 |
|
Rotaerk |
he doesn't really seem to elaborate on "standard" |
| 20:59 |
|
Rotaerk |
to suggest that it must be some global registry of media types is one way of interpreting it but... to build your service only in terms of those seems limiting, and not specifically discouraged by Fielding's paper |
| 21:00 |
|
Rotaerk |
the other principles, as I've mentioned, suggest an expectation that you do otherwise |
| 21:00 |
|
Rotaerk |
sure, have global media types; but not limit yourself to them |
| 21:02 |
|
Rotaerk |
granted, in the case of a representation of an API, that could be a generalized format: a key-value pair mapping names to URIs for all the base resources reachable from the root node |
| 21:02 |
|
Rotaerk |
but still the client must "know" the semantics of those methods... |
| 21:03 |
|
whartung |
but that's documented someplace else, not in the media type |
| 21:03 |
|
Rotaerk |
which would only be inherent to a more specific media type |
| 21:04 |
|
whartung |
also the dissertation is not the be all end all on this, we've been talking about this stuff for years and years. |
| 21:09 |
|
Rotaerk |
hmm, technical communities are susceptible to the bandwagon effect, which can lead to mass adoption of bad practices. I'm not saying that's necessarily the case here... only that because of this, I don't treat popular opinion as more authoritative than well-thought-out, fundamental principles |
| 21:09 |
|
Rotaerk |
community developed interpretations and whatnot can be useful to think about though; they might even make it better |
| 21:10 |
|
Rotaerk |
but I do approach to re-think it from the basics, rather than just go with the popular opinion |
| 21:10 |
|
Rotaerk |
err do prefer to * |
| 21:11 |
|
Rotaerk |
but it seems like what you're suggesting is that the community has deviated from the original principles; REST no longer refers to Fielding's rules very strictly |
| 21:12 |
|
Rotaerk |
(not necessarily a bad thing if there are flaws in the original principles!) |
| 21:12 |
|
whartung |
Let me quote this: |
| 21:12 |
|
whartung |
"Think of it in terms of the Web. How many Web browsers are aware of the distinction between an online-banking resource and a Wiki resource? None of them. They don’t need to be aware of the resource types. What they need to be aware of is the potential state transitions — the links and forms — and what semantics/actions are implied by traversing those links. A browser represents them as distinct UI controls so that a user can see |
| 21:12 |
|
whartung |
potential transitions and anticipate the effect of chosen actions. A spider can follow them to the extent that the relationships are known to be safe. Typed relations, specific media types, and action-specific elements provide the guidance needed for automated agents." |
| 21:14 |
|
whartung |
It's clear he's talking about HTML here, that much is obvious. Obviously, Amazon works just fine with a "web client" as well as wikipedia. Same media type, different applications. |
| 21:14 |
|
whartung |
fair to assume that HTML is not Amazon specific, nor Wiki specific. |
| 21:15 |
|
Rotaerk |
a browser doesn't need application-specific information in order to render a web-page |
| 21:16 |
|
whartung |
Note this: "What they need to be aware of is … what semantics/actions are implied by traversing those links. " |
| 21:16 |
|
Rotaerk |
a client application will require api-specific constraints though |
| 21:16 |
|
Rotaerk |
hmm |
| 21:16 |
|
whartung |
The CLIENT needs to be aware of the SEMANTICS of TRAVERSING the links. |
| 21:16 |
|
Rotaerk |
right |
| 21:17 |
|
Rotaerk |
but the links are provided within the media |
| 21:17 |
|
whartung |
There is nothing in the HTML spec about what the "checkout" rel does |
| 21:17 |
|
Rotaerk |
so the client must know how to process that media in order to know what links to expect, what semantics are associated with them |
| 21:18 |
|
whartung |
yes |
| 21:18 |
|
Rotaerk |
html doesn't need to know anything about specific links; HTML is specific enough for rendering a web page |
| 21:19 |
|
Rotaerk |
but a client that is looking for a link called X must expect a more specific media type...one that guarantees an X link |
| 21:19 |
|
whartung |
HTML is enough to annotate the data (so the client can tell a quantity from a shipping weight), as well as what is a link and what is not. |
| 21:19 |
|
Rotaerk |
the client in the case of HTML is the browser; the browser need not know the difference between a quantity and a shipping weight |
| 21:20 |
|
trygvis |
Rotaerk: it's the internet, there are no guarantees |
| 21:20 |
|
whartung |
but HTML is perfectly adequate for M2M transactions as well. Google somehow manages to suss out prices from God knows how many websites, using just HTML…imagine that…unpossible! |
| 21:21 |
|
Rotaerk |
whartung: I never claimed that the approach of using out-of-band information to determine how to handle the returned content is not doable |
| 21:21 |
|
Rotaerk |
I'm just saying that it appears to be un-RESTful |
| 21:21 |
|
Rotaerk |
so pointing out that there are sites which do it... doesn't help |
| 21:22 |
|
Rotaerk |
trygvis:that's a good point; it could say "html" is the media type and instead return a bitmap |
| 21:22 |
|
Rotaerk |
no guarantees |
| 21:23 |
|
|
rosstuck joined #rest |
| 21:23 |
|
trygvis |
having a more specific media type is not useful, it becomes single purpose so instead the web has settled on a small set of generic media types and let applications layer requirements/expectations on top |
| 21:24 |
|
Rotaerk |
seems like REST should be redefined to account for that |
| 21:25 |
|
trygvis |
settled is the wrong word, it is and will continue to evolve |
| 21:25 |
|
Rotaerk |
though, I don't understand the problem with "single-purpose" |
| 21:25 |
|
Rotaerk |
media types need not be reusable in other APIs |
| 21:25 |
|
trygvis |
you draw some really strange conclusions |
| 21:25 |
|
Rotaerk |
the generic ones, fine; but not all need to be... |
| 21:26 |
|
trygvis |
I suggest you try to implement something instead of just reading |
| 21:27 |
|
Rotaerk |
yea I plan to; I'm just working out the design while thinking about how REST should be applied |
| 21:30 |
|
fumanchu_ |
with extreme prejudice :) |
| 21:30 |
|
Rotaerk |
to me it seems that the idea of using only generic media types, and then putting API-specific details on top of that is akin to... |
| 21:31 |
|
Rotaerk |
creating a C# interface called: IInterface { Dictionary<string, object> Members; } |
| 21:31 |
|
Rotaerk |
and using that in place of .. any other interface |
| 21:32 |
|
Rotaerk |
sure it's really generic and reusable, but it doesn't tell you the exposed members at the type level |
| 21:32 |
|
Rotaerk |
it's meaninglessly reusable |
| 21:33 |
|
trygvis |
that is not far from it. just replace the dictionary with a map of maps and add some links with relations and you have HAL |
| 21:33 |
|
Rotaerk |
taking the policy of using generic media types to the extreme... you might as well just have one global media type, and rely on the client to know what it is |
| 21:33 |
|
fumanchu_ |
I like to think of it as the difference between abstract data types and objects |
| 21:34 |
|
* Rotaerk |
has never heard of HAL. |
| 21:34 |
|
Rotaerk |
lemme look into it |
| 21:35 |
|
fumanchu_ |
(a la Cook: http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf) |
| 21:35 |
|
Rotaerk |
I love "ADT"; refers to both "abstract data type" and "algebraic data type" |
| 21:36 |
|
Rotaerk |
I'll have to look over that paper later |
| 21:46 |
|
|
kevinswi_ joined #rest |
| 21:51 |
|
whartung |
here's another example of using common media types for uncommon causes -- by Fielding. |
| 21:51 |
|
whartung |
http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons |
| 21:52 |
|
whartung |
in this case, sending a 10,000 bit array as a GIF. |
| 21:52 |
|
whartung |
you'll note the semantics of the data type have not changed (GIF represent blocks of bits), but what those bit represent DOES change (it's no longer pixels of an imagine) |
| 21:52 |
|
whartung |
*image) |
| 21:53 |
|
|
warehouse13 joined #rest |
| 21:54 |
|
Rotaerk |
bleh, my network blocks that for some reason |
| 21:54 |
|
Rotaerk |
will look at it at home |
| 21:56 |
|
Rotaerk |
whartung: what I'm unclear on is ... media types define semantics for data, for the client to rely on, so if you're going to be inferring semantics on top of that, why bother with media types at all |
| 21:57 |
|
Rotaerk |
why not just infer all the semantics based on out-of-band communication |
| 21:58 |
|
whartung |
commonality of data formats supports reuse for mundane plumbing. (why stream your own bitmap protocol, when you can use an off the shelf GIF library, for example, and get compression, etc. "for free") |
| 21:58 |
|
whartung |
same reason everyone and their grandmother is jumping on JSON as a serialization format |
| 21:58 |
|
whartung |
"anything" can read JSON |
| 21:59 |
|
Rotaerk |
not really |
| 21:59 |
|
Rotaerk |
json, alone, is meaningless; no semantics |
| 21:59 |
|
fumanchu_ |
such reuse certainly makes the design of intermediaries, browsers, and tooling easier |
| 21:59 |
|
whartung |
no, it has semantics to how prmitivies and strcutures and collections are delimited. |
| 22:00 |
|
Rotaerk |
when I was saying to have a custom media type, I wasn't suggesting that you should roll your own basic data format; use json or something |
| 22:00 |
|
Rotaerk |
but the custom media type would be json + some constraints (must have X, Y, Z objects in it) |
| 22:01 |
|
Rotaerk |
it then allows the client to switch to a different handler based on the media type |
| 22:07 |
|
Rotaerk |
anyway, you guys have given me enough to think about |
| 22:07 |
|
Rotaerk |
heading home |
| 22:41 |
|
|
ChrisAnn joined #rest |
| 22:54 |
|
|
angular_mike_ joined #rest |
| 23:04 |
|
sfisque |
fumantchu_ "with extreme prejudice" AMEN, preach on! preach on! |
| 23:24 |
|
prologic |
JSON Schema |
| 23:34 |
|
|
locks joined #rest |
