greptilian logo

IRC log for #rest, 2015-08-05

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

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

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.