| Time |
S |
Nick |
Message |
| 00:00 |
|
sfisque |
https://www.iana.org/assignments/media-types/application/EDI-X12 |
| 00:01 |
|
sfisque |
application/x-x509-ca-cert |
| 00:02 |
|
Rotaerk |
that one's deprecated |
| 00:02 |
|
Rotaerk |
so that's why it didn't show up... |
| 00:02 |
|
fumanchu |
Rotaerk: it is hard to parse Roy's dense vocabulary sometimes. I think you're splitting the wrong hair. In the quote you pasted above, he draws a distinction between "defining the media type(s)" and "existing standard media types" (which might need extending) |
| 00:02 |
|
sfisque |
deprecated just means it will be discontinued at some poiint |
| 00:03 |
|
sfisque |
deprecated != discontinued |
| 00:03 |
|
Rotaerk |
I'd rather not start using a deprecated thing though :P |
| 00:03 |
|
Rotaerk |
fumanchu, well, I'm basing my conclusion that he favors using standardized ones on a blog comment of his |
| 00:03 |
|
sfisque |
then start your own standards body and ratify something |
| 00:03 |
|
Rotaerk |
sfisque, I really don't buy the idea that standards make sense for this |
| 00:04 |
|
Rotaerk |
two different applications may have wildly different needs for the fields associated with a given entity |
| 00:04 |
|
Rotaerk |
heck they may have entities that are unique to them |
| 00:04 |
|
fumanchu |
Rotaerk: sure, we all prefer that. But he also allows for non-standard ones. |
| 00:04 |
|
sfisque |
that's why most standards define fields as "optional" |
| 00:04 |
|
Rotaerk |
what if you want one that's not in it though? |
| 00:05 |
|
Rotaerk |
or many |
| 00:05 |
|
sfisque |
they also define extensible |
| 00:05 |
|
sfisque |
types |
| 00:05 |
|
Rotaerk |
would those be new media types? maybe with +<extended media type> afterwards |
| 00:05 |
|
fumanchu |
sometimes (as long as they support hypermedia) |
| 00:06 |
|
Rotaerk |
yea |
| 00:06 |
|
sfisque |
i disagree. an attribute is not a type |
| 00:06 |
|
Rotaerk |
an attribute not specified in the documentation for the media type must be learned about through out-of-band communication |
| 00:06 |
|
Rotaerk |
communication outside the docs for that media type |
| 00:06 |
|
sfisque |
only if it is "non-standard" |
| 00:07 |
|
sfisque |
which i argue, still does not go against any spirit of rest |
| 00:07 |
|
Rotaerk |
don't see how you can say that |
| 00:07 |
|
sfisque |
i just did |
| 00:07 |
|
Rotaerk |
seems pretty explicitly against it to me.. |
| 00:07 |
|
sfisque |
interpretation |
| 00:07 |
|
sfisque |
i view rest as a design principal, not a rigorous standard |
| 00:08 |
|
sfisque |
it would have been drafted as an rfc and not a white paper if it was rigorous |
| 00:11 |
|
Rotaerk |
whether it's rigorous or not, it's a standard |
| 00:12 |
|
Rotaerk |
if something violates what it describes, that doesn't make it bad necessarily... but it does make it non-REST |
| 00:12 |
|
fumanchu |
anyway Rotaerk: use standard media types when you can, extending them if you need to and they allow it. When that's not sufficient, Roy's blog post tells you some of the ways APIs screw it up. |
| 00:12 |
|
Rotaerk |
fumanchu, do you happen to remember which blog post? |
| 00:13 |
|
fumanchu |
the one you quoted :D http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven |
| 00:13 |
|
Rotaerk |
you mean one of the comments? |
| 00:13 |
|
Rotaerk |
I read through most of them; don't remember him addressing this |
| 00:13 |
|
fumanchu |
no, although those comments are worth reading too |
| 00:14 |
|
Rotaerk |
what are you referring to when you say that it tells you some ways in which APIs screw up the situation in which a standard media type is insufficient? |
| 00:16 |
|
fumanchu |
to paraphrase his bullet points: when making a REST API, don't assume HTTP is the only protocol, don't try to "fix" HTTP, don't hard-code relationships between URI's in the client (just follow links) |
| 00:17 |
|
Rotaerk |
fumanchu, hmm that does bring up another question from me, but I don't see how it relates to standard vs custom media types |
| 00:17 |
|
Rotaerk |
regarding media types, my primary issue is the claim that you should rarely have custom ones, yet I don't see how they could be so rare; seems like standard ones would be the minority |
| 00:18 |
|
Rotaerk |
unless you standardized all your custom ones... and no other service ended up using them |
| 00:21 |
|
fumanchu |
I believe that's exactly what he means by "typed" resources |
| 00:21 |
|
Rotaerk |
the representations are typed; not the resources |
| 00:21 |
|
fumanchu |
the only "type" that a client should care about is e.g. "this Content is JSON", not "this resource is a Person" |
| 00:21 |
|
fumanchu |
that does *not* mean that there can't be a Person struct inside the JSON payload |
| 00:21 |
|
Rotaerk |
how can the client do anything with the data if it doesn't know anything more than that it's encoded in JSON |
| 00:22 |
|
Rotaerk |
a person could be encoded in it with a "json" media type, sure; but if that's all the client knows, then they can't actually parse out the data |
| 00:22 |
|
Rotaerk |
if the client is a browser, that's fine; it doesn't need to... it just presents it to the user and lets them figure out what it means |
| 00:23 |
|
Rotaerk |
my focus is on REST APIs to be consumed by processes, not people |
| 00:23 |
|
Rotaerk |
(people *could* consume them as well, but that's not my focus) |
| 00:25 |
|
fumanchu |
sure. again, it's a fine hair. What Roy is reacting to in that blog post is APIs where they have defined a xml+Person media type and a xml+Account media type and a xml+ShoppingCart media type and and and |
| 00:25 |
|
sfisque |
rotaerk don't use json then. json is crap |
| 00:25 |
|
fumanchu |
those don't need to be media types |
| 00:25 |
|
Rotaerk |
sfisque, json, xml, any generic data formatting type |
| 00:25 |
|
sfisque |
xml is not generic |
| 00:25 |
|
Rotaerk |
it's specific? |
| 00:25 |
|
Rotaerk |
how? |
| 00:26 |
|
sfisque |
declare the schema or xsd and it becomes VERY specific |
| 00:26 |
|
Rotaerk |
fumanchu, I don't see him reacting to things like that, explicitly... |
| 00:26 |
|
Rotaerk |
which comment #? |
| 00:26 |
|
Rotaerk |
or principle |
| 00:27 |
|
fumanchu |
"A REST API should never have “typed” resources that are significant to the client." |
| 00:27 |
|
Rotaerk |
fumanchu, no that's a different thing |
| 00:28 |
|
Rotaerk |
further down in that paragraph he distinguishes typed resources from typed representations |
| 00:28 |
|
Rotaerk |
"The only types that are significant to a client are the current representation’s media type and standardized relation names." |
| 00:28 |
|
Rotaerk |
xml+Person would be the representations' media type, which *should* be significant to the client |
| 00:29 |
|
fumanchu |
exactly. he is saying it is an antipattern to elevate Person to the level of "media type" |
| 00:29 |
|
Rotaerk |
I don't get that from it |
| 00:29 |
|
Rotaerk |
I think what he means by typed resources is that each resource has different methods |
| 00:29 |
|
fumanchu |
in the same way that we don't elevate <p> to the leve of media type |
| 00:29 |
|
Rotaerk |
<p> isn't a schema |
| 00:29 |
|
Rotaerk |
it's just data within the HTML schema |
| 00:30 |
|
fumanchu |
exactly |
| 00:30 |
|
Rotaerk |
but the set of fields to expect for a Person ... is a schema |
| 00:30 |
|
fumanchu |
no different than the set of attributes or body content to expect for a <p> |
| 00:30 |
|
Rotaerk |
fumanchu, browsers don't expect anything for <p> though; they just render what's there |
| 00:31 |
|
fumanchu |
orly? |
| 00:31 |
|
fumanchu |
onclick? |
| 00:31 |
|
Rotaerk |
that's part of the html spec though, isn't it? |
| 00:31 |
|
fumanchu |
what about <form>? |
| 00:31 |
|
Rotaerk |
i.e. part of the definition of the html media type itself |
| 00:31 |
|
fumanchu |
yes |
| 00:32 |
|
fumanchu |
in a similar manner, the definition a Person should be part of a media type definition (if it's significant to the client), not be the media type itself |
| 00:32 |
|
fumanchu |
*of a Person |
| 00:32 |
|
Rotaerk |
if XHTML was just sent to the browser as xml media type, and the browser used only the media type to determine what to do with it, then it wouldn't be able to render as HTML |
| 00:32 |
|
Rotaerk |
it would treat it like any other XML and just show it |
| 00:33 |
|
Rotaerk |
(unless you did that thing where you provide XML + CSS or whatever) |
| 00:33 |
|
Rotaerk |
XHTML is XML with additional constraints/semantics |
| 00:33 |
|
Rotaerk |
so is xml+person |
| 00:35 |
|
Rotaerk |
s/and just show it/and just show raw XML/ |
| 00:36 |
|
Rotaerk |
sfisque, the XSD/schema certainly gives the client the information it would need to know the structure of the XML, but... it means the client can't request a specific one at the content type level |
| 00:38 |
|
Rotaerk |
though, maybe HTTP media type itself is just unimportant and REST::MediaType != HTTP::MediaType |
| 00:38 |
|
Rotaerk |
REST::MediaType = HTTP::Mediatype + any schema-constraints provided by the format itself? |
| 00:40 |
|
fumanchu |
:/ |
| 00:43 |
|
Rotaerk |
hmm maybe REST is just the wrong paradigm for APIs that aren't merely media providers |
| 00:43 |
|
Rotaerk |
seems meant for clients that just pass the content through to the user |
| 00:50 |
|
Rotaerk |
or... maybe pass-through-client is just the context in which "xml+Person" is bad |
| 00:50 |
|
Rotaerk |
and if the client is a process, xml+Person is fine |
| 00:50 |
|
Rotaerk |
anyway, I think I've frustrated you; probably not going to get these concerns clarified... |
| 01:04 |
|
pdurbin |
Rotaerk: is there a better paradigm for what you're trying to do? |
| 01:06 |
|
Rotaerk |
I dunno; I just don't see how a REST service in which primarily standard media types are used... is viable... if the client needs to be aware of the specific data model for each resource's representations |
| 01:07 |
|
Rotaerk |
i.e. the specific fields that are encoded in the XML/JSON/etc in the representation returned for a given resource |
| 01:08 |
|
Rotaerk |
if the client just says "here, user; this is the JSON/XML/etc the service gave me.", then the client can use generic media types easily... it doesn't need to know anything more specific than those formats |
| 01:09 |
|
Rotaerk |
but if the client is a process that needs to, say, send a text message to the customer returned by the service... |
| 01:09 |
|
Rotaerk |
then it needs to know something more specific than "this is XML/JSON/etc"; it needs to know that it's a customer information, which includes a phone # |
| 01:10 |
|
Rotaerk |
and per the rest principles, the only way it's allowed to know that is with a more specific media type |
| 01:10 |
|
Rotaerk |
not some "out of band" communication that says it's formatted in a specific way as to contain a phone number |
| 01:11 |
|
Rotaerk |
so it seems to me that either you don't use REST, or you use REST but you go against the notion of primarily using standard media types |
| 01:14 |
|
fumanchu |
the solution is to put that communication "in band" |
| 01:16 |
|
Rotaerk |
the only way to do "in band" communication though is in the definition of the media type itself |
| 01:23 |
|
Rotaerk |
I mean, within the constraints of REST; not in general, of course. |
| 01:42 |
|
|
FreezingDroid joined #rest |
| 01:42 |
|
FreezingDroid |
I don't really understand what purpose a callback URL serves. |
| 01:50 |
|
|
kevinswiber joined #rest |
| 01:59 |
|
FreezingDroid |
Hmm, sort of figured it out. |
| 02:03 |
|
sfisque |
freezingdroid for long running processes |
| 02:04 |
|
sfisque |
e.g. an endpoint that returns 202 and you have to get the payload "later" |
| 02:04 |
|
sfisque |
there are many other uses. thats the one that i think is "most obvious" |
| 02:06 |
|
FreezingDroid |
Ah. I don't *think* my API really uses it, but I'm just learning this stuff. |
| 02:06 |
|
sfisque |
rotaerk i'm with fumanchu, you're confusing "media type" with "data type". e.g. if a client receives an image/tiff it's upto the client to interpret it (is it a fax? is it a histogram? is it a photograph?) according to its business rules, not inherent to the media type |
| 02:07 |
|
FreezingDroid |
At the moment I'm using curl to submit GET requests and it's a bit time consuming to keep moving my cursor around, is there a better way of doing this? |
| 02:08 |
|
sfisque |
same for a json block. it's not upto the client to "sniff" what a person it, it has to know what a person is, it's baked into the business rules. but it better know how to extract a csv block or json block to get that person into a usable manner |
| 02:09 |
|
sfisque |
write a client? google for a client? i even believe you can coax soapui to do rest calls |
| 02:10 |
|
sfisque |
freezingdroid ^^^ |
| 02:10 |
|
sfisque |
sorry, forgot to prefix |
| 02:11 |
|
FreezingDroid |
sfisque: This seemed to be a decent one I found. https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo |
| 02:12 |
|
sfisque |
cool |
| 02:12 |
|
sfisque |
:-) |
| 02:24 |
|
|
fuzzyhorns joined #rest |
| 02:24 |
|
|
vanHoesel joined #rest |
| 02:25 |
|
Rotaerk |
sfisque, it sounds like you're saying media type is *not* a contract, that the client doesn't actually get everything it needs to know about the server's response, from the media type documentation |
| 02:25 |
|
Rotaerk |
which seems contrary to the rules.. |
| 02:25 |
|
sfisque |
negative. what i'm saying is, you are loading the term with unreasonable requirements |
| 02:26 |
|
|
baweaver joined #rest |
| 02:26 |
|
sfisque |
the client doesnt get everything it needs from the response. it could never get everything it needs. thats why we have code in teh client, to DO that stuff |
| 02:26 |
|
sfisque |
code fills the gulf |
| 02:26 |
|
Rotaerk |
sfisque, I didn't say the client "get everything it needs from the response" |
| 02:26 |
|
FreezingDroid |
sfisque: failing at the client a little bit lol |
| 02:27 |
|
Rotaerk |
I said the client implementation is based on nothing more than the documentation for the media types |
| 02:27 |
|
Rotaerk |
that is what the rules suggested |
| 02:27 |
|
Rotaerk |
that everything the client needs to know about the service is encapsulated in 1) the media type definitions, and 2) the link relation semantics |
| 02:27 |
|
sfisque |
that third point is NOT even feasible, rest or otherwise |
| 02:28 |
|
Rotaerk |
*not* that the client must magically obtain all the semantics from the response itself |
| 02:28 |
|
sfisque |
it could never be feasible, by definition |
| 02:28 |
|
sfisque |
otherwise the client needs 0 bytes of code |
| 02:28 |
|
Rotaerk |
so basically REST isn't feasible |
| 02:28 |
|
sfisque |
other than a response handler |
| 02:28 |
|
Rotaerk |
or there is some subtlety in the rules that I'm misunderstanding |
| 02:29 |
|
Rotaerk |
because it seems pretty explicit... |
| 02:29 |
|
sfisque |
negative. rest is a not a protocol, standard, OR framework. it's merely a design principal |
| 02:29 |
|
sfisque |
nothing more, nothing less |
| 02:29 |
|
Rotaerk |
a principle that is not feasible to follow |
| 02:29 |
|
sfisque |
it is totally followable, IF you are willing to take it at face value and not overload it with unreasonable expectations :-) |
| 02:29 |
|
Rotaerk |
I wasn't overloading it :\ |
| 02:30 |
|
Rotaerk |
I was taking nothing more than what was described by roy |
| 02:30 |
|
sfisque |
you're expecting the response to tell the client how to do its job |
| 02:30 |
|
Rotaerk |
no I'm not |
| 02:30 |
|
sfisque |
it could never do that, except in the case wehre the code is delievered with the data |
| 02:30 |
|
Rotaerk |
I'm expecting the documentation for the media type to tell the client how to interpret the response |
| 02:30 |
|
Rotaerk |
you keep saying that I'm suggesting that the response tell the client how to do it's job |
| 02:30 |
|
Rotaerk |
I never said that |
| 02:31 |
|
Rotaerk |
s/I'm expecting/the rest principles explicitly state that I should expect/ |
| 02:31 |
|
sfisque |
based on what you are saying, my client should be able to take media type "xxx/yyyy" and be able to infer how it is supposed to interpret the response body |
| 02:31 |
|
Rotaerk |
if that's an unreasonable expectation, then the rest principles are unreasonable |
| 02:32 |
|
Rotaerk |
yes, the documentation for the media type is a schema of the response |
| 02:32 |
|
sfisque |
when in reality "xxx/yyyy" only tells my client how it is supposed to parse/process the stream of data, not how to interpret it |
| 02:33 |
|
sfisque |
a schema only insofar as syntactical correctness, not interpretation |
| 02:34 |
|
sfisque |
think of it like a compiler. the compiler only tells you the code is syntactically correct, but does not infer whether the program is usable, correct, or functional |
| 02:35 |
|
Rotaerk |
why is XHTML not just the XML media type then? |
| 02:35 |
|
Rotaerk |
every XHTML is a valid XML, but not vice-versa |
| 02:35 |
|
Rotaerk |
it's XML with constraints about what is "correct" |
| 02:35 |
|
sfisque |
subset. same applies to mathml or any other DSL based on xml |
| 02:36 |
|
sfisque |
it's constraints on what is syntactically correct, not semantically correct |
| 02:36 |
|
Rotaerk |
right, but a schema for, say, Customer is not about constraining what is semantically correct... the person's name could be "AOEUAOEU" |
| 02:36 |
|
Rotaerk |
it's about unsuring it's syntactically correct: has all the expected fields |
| 02:36 |
|
Rotaerk |
ensuring* |
| 02:37 |
|
sfisque |
but the media type is text/plain (or text/json or text/xml, etc) not text/person unless you want to ratify that type |
| 02:37 |
|
Rotaerk |
why must it be standardized though? what's the point? |
| 02:37 |
|
sfisque |
so when you get that person, the client knows only it is text/json (or whatever) and it parses the block into some native format |
| 02:37 |
|
Rotaerk |
why can't I just create my own media type to encode Customer |
| 02:38 |
|
Rotaerk |
and communicate the definition/schema for it to my consumers |
| 02:38 |
|
Rotaerk |
no need to make it global |
| 02:38 |
|
Rotaerk |
I don't understand why that's ... discouraged |
| 02:38 |
|
sfisque |
you can. similarly to how soap publishes its schema/wsdl, you can have a rest endpoint that exposes a rule/schema/constraint doc that your client consumes and uses to process the block |
| 02:39 |
|
sfisque |
your json block can have a reference to a schema/rule executable/lib/script/whatever if that is how you want to do it |
| 02:40 |
|
sfisque |
or you can return a header that tells the client where to find the parsing script/schema/whatever |
| 02:40 |
|
sfisque |
but expecting the media-type to do that for you is expecting too much i believe and not in the design for that specific feature |
| 02:40 |
|
Rotaerk |
hrm, the media type definitions are for the developer, not the client |
| 02:40 |
|
Rotaerk |
client "discovering" the media type doesn't make sense |
| 02:40 |
|
sfisque |
right |
| 02:41 |
|
sfisque |
it's more for 'handling" on the client side. aka, i receive a pdf stream, so i now engage my pdf parser module |
| 02:41 |
|
sfisque |
now whether i slice up that pdf, render it, or post process it is upto the client code and out of band of the response |
| 02:43 |
|
sfisque |
so bascially its for "both" but for different reasons. the media type is for the dev so they can write the "interpretation" layer. it's for the client so they can invoke the correct handler code before interpretation takes over |
| 02:47 |
|
Rotaerk |
hmm k |
| 02:47 |
|
Rotaerk |
at this point it seems like REST doesn't buy you much |
| 02:47 |
|
Rotaerk |
because there's still coupling between the client and the server |
| 02:48 |
|
Rotaerk |
i.e. the client must know that the, say, JSON/XML from *this* service resource... is going to be providing customer data |
| 02:49 |
|
Rotaerk |
then again, the principles also say that the client can determine which methods to use on a resource, in the link relations... |
| 02:49 |
|
Rotaerk |
but the link relation can't tell the client *what* to POST to a resource |
| 02:49 |
|
Rotaerk |
only that it can be posted to |
| 02:50 |
|
Rotaerk |
so it's like... the illusion of decoupling |
| 02:52 |
|
sfisque |
well it is. the cohesion gets reduced because unlike most RPC style endpoints, you're stateless and the protocol is platform independent. conversely if you're talking RMI or CORBA or similar RPC techs, you're usually tied to some platform or language (java, C, C++, Delphi, etc.) |
| 02:52 |
|
sfisque |
but it doesnt remove cohesion. no fabric has zero cohesion |
| 02:53 |
|
sfisque |
it would be impossible by definition. |
| 02:53 |
|
sfisque |
even humans interacting via voice suffer api cohesion |
| 02:53 |
|
sfisque |
we assume words mean the same thing or require the same language or other constructs |
| 02:53 |
|
sfisque |
machine <-> machine suffers this no less as well |
| 02:54 |
|
sfisque |
rest is an attempt to reduce cohesion, not eliminate it, because you can't |
| 02:54 |
|
Rotaerk |
k |
| 02:57 |
|
sfisque |
the tough part and a few other fellows in channel will (and have) remark that rest leaves a fair bit "open to interpretation" and that's (i feel) intentional because i think its meant as a design principal and not an architecture definition |
| 02:58 |
|
Rotaerk |
yea seems like it |
| 03:04 |
|
Rotaerk |
thanks for the clarification |
| 03:12 |
|
sfisque |
no worries. i like these discussions because i'm still learning about rest, too. in a way, we all are, because how it gets implemented is kind of evolving as we speak |
| 03:13 |
|
Rotaerk |
I just want to make sure I'm not in a situation where I make a "restful" service that's not even remotely restful |
| 03:13 |
|
Rotaerk |
which seems to be popular |
| 03:13 |
|
Rotaerk |
it's the hip buzzword these days |
| 03:13 |
|
sfisque |
amen to that |
| 03:14 |
|
sfisque |
i even said other day that it will be interesting when the "frenzy" dies down and people just realize that rest is just another tool for the toolbox and not a silver bullet or panacea |
| 03:20 |
|
|
warehouse13 joined #rest |
| 03:38 |
|
|
foist joined #rest |
| 03:55 |
|
Rotaerk |
heh |
| 03:55 |
|
Rotaerk |
https://kenai.com/projects/suncloudapis/pages/Home |
| 03:55 |
|
Rotaerk |
this seems to do what I was suggesting... |
| 03:55 |
|
Rotaerk |
custom media types |
| 03:56 |
|
Rotaerk |
etc application/vnd.com.sun.cloud.VDC+json |
| 03:56 |
|
Rotaerk |
doesn't appear to be registered |
| 03:59 |
|
sfisque |
sort of. it looks like a management endpoint api, but i guess you "could" generify it to apply to application endpoints |
| 03:59 |
|
|
vanHoesel joined #rest |
| 03:59 |
|
sfisque |
basically provisioning rest api |
| 04:00 |
|
Rotaerk |
hmm I thought we were always talking about rest apis |
| 04:01 |
|
sfisque |
right but it looks like it's an api for provisioning discovery, not introspection of the endponts themselves |
| 04:02 |
|
sfisque |
it just occurred to me, you're looking for a way to make rest reflective/introspective |
| 04:02 |
|
sfisque |
so the client can infer deeper semantics on response payloads |
| 04:07 |
|
Rotaerk |
not exactly |
| 04:08 |
|
Rotaerk |
I'm not looking to make the client itself somehow smarter |
| 04:08 |
|
Rotaerk |
the media type definition is for consumption by the developer, not the client; but apparently additional schematic information is also consumed by the developer |
| 04:09 |
|
Rotaerk |
if you don't use per-schema content types |
| 04:13 |
|
sfisque |
aye |
| 04:15 |
|
Rotaerk |
hmm since the URIs' structure should basically be ignored by the client |
| 04:16 |
|
Rotaerk |
and since the media type doesn't tell you what is going to be in the response, specifically |
| 04:16 |
|
Rotaerk |
it seems like the only thing that should tell your client how to begin parsing it is... the link relation type |
| 04:18 |
|
Rotaerk |
"I reached this resource via a link called 'customers', so I will accept JSON and parse it using *this* logic" |
| 04:18 |
|
|
talios joined #rest |
| 04:18 |
|
sfisque |
basically, true |
| 04:19 |
|
Rotaerk |
also if the link relation is a POST, then the relation type tells it *what* to post |
| 04:19 |
|
sfisque |
though there are mechs for introspection, but you have to leverage them or invent them, depending on details (xml schema, standard object models [HL7, NACHA, etc.], or "ship the code with the data" ) |
| 04:19 |
|
Rotaerk |
err the link method is a post* |
| 04:20 |
|
sfisque |
aye |
| 04:21 |
|
sfisque |
afaik there is no "standard" mech or guiding design for introspection in rest |
| 04:25 |
|
Rotaerk |
heh http://soabits.blogspot.com/2013/05/the-role-of-media-types-in-restful-web.html |
| 04:27 |
|
sfisque |
i like this line: With this blog post I will try to explain how a media type, with a sufficient number of hyper media controls, together with some intelligent client side code, can enable what Fielding is describing |
| 04:27 |
|
sfisque |
in effect he even admits that the client needs to "know" something |
| 04:32 |
|
sfisque |
so he basically details a form of "ship the code with the client". basically the link at http://bugme.org/names/create-bug-report would take raw data and compile it into a "payload" that can in turn then be POST/PUT'ed to joe's server at /~joe/track/add-issue |
| 04:50 |
|
|
vanHoesel joined #rest |
| 04:58 |
|
Rotaerk |
yea I was thinking media types were all about the schema of the content, but it seems more about... |
| 04:58 |
|
Rotaerk |
the schema of the links |
| 04:59 |
|
Rotaerk |
different generic media types have different ways of providing metadata for links |
| 05:02 |
|
Rotaerk |
and I think part of the reason I was misunderstanding is that Roy seems to make some implicit assumptions when stating generalizations |
| 05:03 |
|
Rotaerk |
e.g. "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" |
| 05:03 |
|
Rotaerk |
"no prior knowledge" ... specifically, no prior knowledge about the service's URI structure |
| 05:20 |
|
|
kevinswiber joined #rest |
| 09:11 |
|
|
quimrstorres joined #rest |
| 10:22 |
|
|
graste joined #rest |
| 13:25 |
|
|
quimrstorres joined #rest |
| 13:29 |
|
|
kevinswiber joined #rest |
| 13:40 |
|
|
fuzzyhorns joined #rest |
| 13:41 |
|
fuzzyhorns |
mamund: i want to make a matrix of formats x hfactors -- do you still think hfactors make sense as a rubric for comparison? |
| 14:39 |
|
pdurbin |
https://github.com/cadecairos/cookie-js via "what's a good way to get session info in react?" at http://logs.glob.uno/?c=mozilla%23sciencelab&s=4+Jun+2015&e=4+Jun+2015#c7210 |
| 14:50 |
|
|
quimrstorres joined #rest |
| 15:03 |
|
|
quimrstorres joined #rest |
| 15:20 |
|
|
nkoza joined #rest |
| 15:53 |
|
|
baweaver joined #rest |
| 15:59 |
|
|
quimrstorres joined #rest |
| 16:35 |
|
|
alxbl joined #rest |
| 16:35 |
|
|
sfisque joined #rest |
| 17:11 |
|
|
alxbl joined #rest |
| 17:54 |
|
|
quimrstorres joined #rest |
| 18:11 |
|
|
quimrstorres joined #rest |
| 19:02 |
|
|
quimrstorres joined #rest |
| 19:32 |
|
|
graste joined #rest |
| 19:36 |
|
|
quimrstorres joined #rest |
| 19:38 |
|
|
quimrstorres joined #rest |
| 19:47 |
|
|
sfisque joined #rest |
| 19:50 |
|
|
Coldblackice joined #rest |
| 20:05 |
|
|
fuzzyhorns joined #rest |
| 22:00 |
|
|
vanHoesel joined #rest |
| 22:08 |
|
|
quimrstorres joined #rest |
| 22:11 |
|
|
quimrstorres joined #rest |
| 22:14 |
|
|
vanHoesel joined #rest |
| 22:25 |
|
|
fuzzyhor_ joined #rest |
| 22:43 |
|
|
Jefffrey joined #rest |
| 22:51 |
|
|
quimrstorres joined #rest |
| 22:59 |
|
|
spaceone joined #rest |
| 23:17 |
|
|
quimrstorres joined #rest |
