| Time |
S |
Nick |
Message |
| 00:13 |
|
|
fuzzyhorns joined #rest |
| 01:36 |
|
|
wsiqueir joined #rest |
| 03:02 |
|
|
fuzzyhorns joined #rest |
| 03:40 |
|
|
baweaver joined #rest |
| 04:37 |
|
|
sfisque joined #rest |
| 05:37 |
|
|
whartung_ joined #rest |
| 06:01 |
|
|
_ollie joined #rest |
| 07:41 |
|
|
quimrstorres joined #rest |
| 07:42 |
|
|
quimrstorres joined #rest |
| 07:57 |
|
|
rosstuck joined #rest |
| 08:34 |
|
|
quimrstorres joined #rest |
| 08:47 |
|
|
graste joined #rest |
| 09:01 |
|
|
quimrstorres joined #rest |
| 09:24 |
|
|
darkschneider joined #rest |
| 09:28 |
|
darkschneider |
hello, i have a simple rest beckend that i wrote for CRUD operations, my objects have some extra operations that can be performed (something not easily representable as a state change) and i was thinking about sending down urls to perform those operations along with the objects (in the end it's like sending down "actions") anyone can suggest some article or some good google keywords for a search? (i'm sure this things has a name) |
| 09:29 |
|
_ollie |
i guess what you're looking for is hypermedia… |
| 09:30 |
|
darkschneider |
possible, my terminology knowledge is very low, i may be looking for "mom" and i would not know (hey here is my milk!) |
| 09:30 |
|
_ollie |
what's your tech stack? |
| 09:31 |
|
darkschneider |
lamp+dojo |
| 09:31 |
|
|
quimrstorres joined #rest |
| 09:31 |
|
darkschneider |
if that was the question :) |
| 09:31 |
|
darkschneider |
btw, thanks hypermedia may be making a sense |
| 09:32 |
|
trygvis |
darkschneider: what you're describing is basically hypermedia. data+controls |
| 09:32 |
|
_ollie |
hm, not my area of expertise… yeah, it's a vague question. |
| 09:32 |
|
darkschneider |
yep, sorry i wanted only to have some google keywords or articles you knwo are good on the topic |
| 09:33 |
|
darkschneider |
actually just the word "hypermedia" is of great help :) |
| 09:34 |
|
darkschneider |
it's hard to google something you can describe but you do not know the name (search for "mom" by "gives you milk when you are a baby" :D ). if you have a link also i accept it and read. thanks both :) |
| 09:40 |
|
trygvis |
so now your problem becomes picking the right hypermedia :) |
| 09:40 |
|
darkschneider |
arf :D |
| 09:40 |
|
darkschneider |
help :D |
| 09:41 |
|
darkschneider |
i see many speak of HATEOAS |
| 09:41 |
|
trygvis |
yep |
| 09:41 |
|
darkschneider |
as you may guess i have no clue and no expertise to judge.. |
| 09:42 |
|
darkschneider |
i'll see what client library (dojo in my case) likes more, as the server side i'll write myself |
| 09:57 |
|
|
quimrstorres joined #rest |
| 10:08 |
|
|
ionas joined #rest |
| 10:24 |
|
|
quimrstorres joined #rest |
| 10:28 |
|
|
quimrstorres joined #rest |
| 11:57 |
|
|
quimrstorres joined #rest |
| 12:25 |
|
|
quimrstorres joined #rest |
| 12:42 |
|
_ollie |
I have a resource that returns a JSON based representation by default. What's the best way to advertise other available media types? |
| 12:42 |
|
_ollie |
I know I can link to other resources (or even the same), but I don't want to invent a new relation name for every additional media type I serve. |
| 12:43 |
|
|
interop_madness joined #rest |
| 13:05 |
|
trygvis |
some hypermedias have a "type" attribute on their "link" concept |
| 13:06 |
|
_ollie |
We're using HAL currently. |
| 13:06 |
|
trygvis |
so you could have list of links with rel="alternate" and type=".." |
| 13:07 |
|
trygvis |
looks like it is supported: https://tools.ietf.org/html/draft-kelly-json-hal-07#section-5.3 |
| 13:08 |
|
_ollie |
Hm, nice. |
| 13:10 |
|
_ollie |
So I could add additional links pointing to the same URI but different types. |
| 13:11 |
|
trygvis |
that would work, yes |
| 13:12 |
|
_ollie |
But then the clients would have to deal with the possibility of the value ofor the enty in the _links object bei either an array or a single link object. |
| 13:13 |
|
_ollie |
That's something we tried to avoid so far. |
| 13:30 |
|
|
fuzzyhorns joined #rest |
| 13:32 |
|
trygvis |
they have to support that if you're using HAL, it is a part of the HAL specification |
| 13:32 |
|
trygvis |
same with CURIES |
| 13:34 |
|
_ollie |
Well I see that to be generally true. But assume we exposed a rel that has been a single link object so far (e.g. profile) and now all of a sudden start returning an array instead. |
| 13:35 |
|
trygvis |
well, that is kinda too bad for the client if they're not following the spec |
| 13:35 |
|
_ollie |
I don't agree that this has to do. |
| 13:35 |
|
_ollie |
… with the spec. What you're suggesting is basically changing the semantics of a link relation. |
| 13:37 |
|
_ollie |
I could definitely use that if I started from scratch. |
| 13:38 |
|
trygvis |
I don't follow, what is changing the semantics? |
| 13:39 |
|
_ollie |
let's say I've defined the "foo" relation to *always* be a single link. |
| 13:39 |
|
trygvis |
you can do that in your application, but HAL says it can be either an array or an object: https://tools.ietf.org/html/draft-kelly-json-hal-07#section-4.1.1 |
| 13:39 |
|
_ollie |
I know. |
| 13:40 |
|
_ollie |
That doesn't help my client using the well-defined semantics of my link relations. |
| 13:41 |
|
|
quimrstorres joined #rest |
| 13:41 |
|
trygvis |
it sounds to me that you have locked yourself into a corner by overspecifying how the list of links will be |
| 13:43 |
|
_ollie |
I did not specify anything. I just assume that there are clients that have made this assumption :). |
| 13:43 |
|
trygvis |
but I guess you can just make another link relation with the new semantics and get clients to move to that one |
| 13:43 |
|
_ollie |
So while I agree with you in theory, I guess I can't just break the clients, even it it's their fault. |
| 13:43 |
|
trygvis |
to be honest I would probably just teach them and do the change. if they're using any sane library it should be handled by the library |
| 13:44 |
|
trygvis |
ok, so then you have to invent something extra outside the spec |
| 13:44 |
|
trygvis |
and hope that your client's allow new fields :) |
| 13:44 |
|
_ollie |
I don't want to move away from IANA rels actually. |
| 13:45 |
|
_ollie |
I just read up on this one here… https://groups.google.com/forum/#!topic/hal-discuss/nkPvZW1RXEc |
| 13:45 |
|
_ollie |
Interesting point by Mike actually. Content negotiation could be an option, too. |
| 13:46 |
|
trygvis |
yes, but I though the idea was to tell the clients up front |
| 13:46 |
|
_ollie |
Because the client basically *hhas* to know up front, which media types it can generally deal with. |
| 13:46 |
|
trygvis |
right, so content-negotiation is off the table |
| 13:47 |
|
trygvis |
or perhaps you could use OPTIONS, but I'm not sure if that is useful for conneg |
| 13:47 |
|
_ollie |
Well, what I mean is: even if we have a more explicit way to advertise a media type available for a resource - is that of value actually? |
| 13:48 |
|
_ollie |
Because, suppose the client detects a media type unknown, what would it do with it? |
| 13:48 |
|
trygvis |
that is always a problem |
| 13:48 |
|
trygvis |
for the server it is useful to say that you can get this as a PDF or a excel sheet. the xls points to the raw endpoint, while the PDF goes through a converter service |
| 13:48 |
|
_ollie |
Okay, so acknowledging that, relying on content negotiation might not be a bad idea here, as the client can basically expose what it's capabale of dealing with. |
| 13:48 |
|
trygvis |
so if the client could pick the right one directly it would be useful for the server |
| 13:49 |
|
trygvis |
if you have to know *up front* you can't use conneg |
| 13:49 |
|
_ollie |
In my concrete example we currently serve ALPS via a profile link |
| 13:50 |
|
_ollie |
that in turn points to a JSON schema from one of the descriptors |
| 13:51 |
|
_ollie |
Now I wondered what would be a good way to tell the client: actually, if you prefer to only know about the data structures, you could just ask for JSON schema on that profile resource, too. |
| 13:54 |
|
trygvis |
I'll be putting a rel="schema" on my json objects soon |
| 13:55 |
|
trygvis |
which will point to a Fiken specific schema format, mainly useful for our clients and the hal-browser thingy I'll make |
| 13:56 |
|
_ollie |
hehe, basically we're trying to build something similar for the HAL browser |
| 13:56 |
|
_ollie |
but I didn't want to invent a separate "schema" rel |
| 13:57 |
|
trygvis |
hm, isn't there a schema rel already? |
| 13:57 |
|
_ollie |
even more so, I wanted to avoid a dedicated resource exposing the schema… |
| 13:58 |
|
trygvis |
where would be it be then? inline? |
| 13:58 |
|
_ollie |
so i thought I could just leverage content negotiation for /foo to basically serve HAL by default but JSON schema if requested… and profile basically pointing to the same resource |
| 13:58 |
|
trygvis |
ah, ok |
| 13:58 |
|
_ollie |
Not entirely convinced this is a good idea though. |
| 13:58 |
|
trygvis |
but then people would need to know that fact out of bounds |
| 13:59 |
|
_ollie |
I liked the fact that the resource you'd POST to basically exposes what it expects to get posted by that |
| 13:59 |
|
trygvis |
and if /foo/1 and /foo/2 are two different resources but the same "type" it would be kinda strange to get two different but equal schemas |
| 13:59 |
|
|
quimrstorres joined #rest |
| 13:59 |
|
_ollie |
http://www.iana.org/assignments/link-relations/link-relations.xhtml doesn't have a schema link relation |
| 14:00 |
|
trygvis |
there's 'describedby' |
| 14:00 |
|
trygvis |
right, I was just looking at that |
| 14:00 |
|
_ollie |
hm, yeah. |
| 14:00 |
|
_ollie |
that's just as vague as profile… |
| 14:01 |
|
_ollie |
I've always considered profile to point to something more than just the data/schema aspect |
| 14:01 |
|
trygvis |
I guess it makes sense that the POST location would tell you what it expects, but I think it is normally done on the resource where you're posting "from" |
| 14:01 |
|
trygvis |
they're all vague :) |
| 14:01 |
|
trygvis |
I think it's a feature |
| 14:02 |
|
_ollie |
i liked profile better than describedby because in fact the schema describes the domain specific aspect of the JSON returned |
| 14:02 |
|
trygvis |
hm, I think profile usually is related to features of the current document |
| 14:03 |
|
_ollie |
Maybe just because I found described by too much connected to that POWDER format |
| 14:03 |
|
_ollie |
yeah so for interpreting, it feels more natural to expose profile on the item resources (/foo/4711) |
| 14:04 |
|
_ollie |
because then you have a direct match to the properties you find in the document |
| 14:04 |
|
_ollie |
for the collection resource it's describing the format expected for a given HTTP method |
| 14:05 |
|
_ollie |
all of that sometimes makes me think it's rather correct to not expose a schema without context, i.e. something like ALPS that documents state transitions, too. |
| 14:05 |
|
_ollie |
… and has means to indicate whether the schema exposed is considered the request or the response side of things |
| 14:08 |
|
_ollie |
Our current HAL Browser extension just looks up the schema from a well known resource and creates a dynamic form to issue POST requests. I'd like to change that to a hopefully generic discovery of the schema. |
| 14:08 |
|
trygvis |
sounds similar to what we want, but I'll point to it from a link relation |
| 14:08 |
|
_ollie |
and you're going to use which relation? |
| 14:09 |
|
trygvis |
maybe we'll just put it under our own relation tree |
| 14:09 |
|
_ollie |
https://jira.spring.io/browse/DATAREST-627 |
| 14:10 |
|
_ollie |
Here's what we're trying to do: https://github.com/spring-projects/spring-data-rest/pull/191/files#diff-9713863203f5d1360c487d39265c94e1R1 |
| 14:10 |
|
_ollie |
I forgot we considered curies, too. |
| 15:59 |
|
|
Coldblackice joined #rest |
| 16:28 |
|
angular_mike_ |
How restful is this API: http://developer.openstack.org/api-ref-compute-v2-ext.html ? |
| 17:08 |
|
trygvis |
listing a set of URL patterns is always a bad start |
| 18:35 |
|
|
quimrstorres joined #rest |
| 18:41 |
|
|
Wildblue` joined #rest |
| 18:52 |
|
|
quimrstorres joined #rest |
| 19:12 |
|
|
ionas joined #rest |
| 19:42 |
|
|
darkschneider joined #rest |
| 20:49 |
|
|
adaro joined #rest |
| 21:34 |
|
|
fuzzyhorns joined #rest |
| 21:38 |
|
|
daxim_ joined #rest |
| 22:54 |
|
|
fuzzyhorns joined #rest |
| 23:42 |
|
|
darkschneider joined #rest |
