| Time |
S |
Nick |
Message |
| 00:48 |
|
|
fumanchu joined #rest |
| 00:59 |
|
|
WaRLoRD786 joined #rest |
| 01:36 |
|
|
fuzzyhorns joined #rest |
| 01:42 |
|
|
vanHoesel joined #rest |
| 01:43 |
|
|
fuzzyhorns joined #rest |
| 02:35 |
|
|
sfisque joined #rest |
| 03:02 |
|
|
baweaver joined #rest |
| 03:24 |
|
|
FreezingDroid joined #rest |
| 03:25 |
|
|
fuzzyhorns joined #rest |
| 04:01 |
|
|
vanHoesel joined #rest |
| 04:20 |
|
|
fuzzyhorns joined #rest |
| 04:32 |
|
|
vanHoesel joined #rest |
| 05:14 |
|
|
fuzzy_horns joined #rest |
| 06:06 |
|
|
locks joined #rest |
| 06:14 |
|
|
rickharrison joined #rest |
| 06:15 |
|
|
Left_Turn joined #rest |
| 06:18 |
|
|
ChrisAnn joined #rest |
| 06:39 |
|
|
ramsey joined #rest |
| 07:01 |
|
|
angular_mike_ joined #rest |
| 07:03 |
|
|
fuzzy_horns joined #rest |
| 07:10 |
|
|
bigbluehat joined #rest |
| 07:16 |
|
|
interop_madness joined #rest |
| 07:30 |
|
|
ekroon joined #rest |
| 07:38 |
|
|
blahdeblah joined #rest |
| 07:39 |
|
|
fuzzy_horns joined #rest |
| 08:06 |
|
|
FreezingDroid joined #rest |
| 08:08 |
|
|
graste joined #rest |
| 08:16 |
|
|
Coldblackice joined #rest |
| 08:40 |
|
|
fuzzy_horns joined #rest |
| 09:52 |
|
|
quimrstorres joined #rest |
| 10:28 |
|
|
fuzzy_horns joined #rest |
| 12:17 |
|
|
fuzzy_horns joined #rest |
| 12:44 |
|
|
kevinswiber joined #rest |
| 12:44 |
|
|
fuzzyhorns joined #rest |
| 12:45 |
|
|
kevinswiber joined #rest |
| 13:18 |
|
|
fuzzy_horns joined #rest |
| 13:58 |
|
|
kevinswiber joined #rest |
| 14:23 |
|
|
nkoza joined #rest |
| 15:02 |
|
|
nkoza joined #rest |
| 15:07 |
|
|
fuzzyhorns joined #rest |
| 15:14 |
|
|
vanHoesel joined #rest |
| 15:48 |
|
|
ralphschindler joined #rest |
| 15:49 |
|
pdurbin |
Linked Data Platform 1.0 - http://www.w3.org/TR/ldp/ ... is this awesome? |
| 15:53 |
|
|
baweaver joined #rest |
| 15:58 |
|
pdurbin |
hearing about it at https://docs.google.com/presentation/d/14hVDx2xQYy8zUEmYHHwdCwvmpmBfOyIyCxyP46I9AHc/edit?usp=sharing |
| 16:08 |
|
fumanchu |
meh. with only a structure for containment, not collection, it's not very "linked". no facility for secondary indexes means pretty low efficiency in my experience. |
| 16:23 |
|
pdurbin |
fumanchu: by "not collection" you mean it's read-only? |
| 16:24 |
|
fumanchu |
I mean there's no way to make a collection that refers to resources that aren't "owned" by the collection |
| 16:25 |
|
fumanchu |
the only way to add an item to the Container is to create a new item |
| 16:25 |
|
pdurbin |
hmm, ok |
| 16:25 |
|
fumanchu |
what if I already have a million items and I want to make a list of my favorites? |
| 16:26 |
|
fumanchu |
that would be a "secondary index" that collects items without containing them |
| 16:27 |
|
fumanchu |
which then allows real linking since the items I collect on my service don't even have to live on my server |
| 16:30 |
|
|
fuzzyhorns joined #rest |
| 16:32 |
|
pdurbin |
fumanchu: so you would be a curator in this case |
| 16:34 |
|
fumanchu |
yes, but the same principle applies to lots of secondary indexes (and orders) that aren't auto-generated from item attributes |
| 16:35 |
|
fumanchu |
I just find it odd that a spec designed to facilitate linking allows you to link to...only your own stuff |
| 16:36 |
|
|
foist joined #rest |
| 16:50 |
|
|
kevinswiber joined #rest |
| 16:55 |
|
|
fuzzyhorns joined #rest |
| 16:58 |
|
|
vanHoesel joined #rest |
| 17:10 |
|
|
vanHoesel joined #rest |
| 17:12 |
|
|
quimrstorres joined #rest |
| 17:23 |
|
|
vanHoesel joined #rest |
| 17:50 |
|
|
fuzzyhorns joined #rest |
| 18:25 |
|
fuzzyhorns |
i have an architecture oriented question for yall |
| 18:25 |
|
fuzzyhorns |
the dir of arch where im at wants to implement a system |
| 18:25 |
|
whartung |
greek columns…and lots of marble |
| 18:26 |
|
fuzzyhorns |
where it is roughly layered like this: clients; client-focused apis; resource based apis; datasources |
| 18:26 |
|
fuzzyhorns |
this seems... wrong... to me -- but i wondered if anyone has done something like this and what their experience was |
| 18:26 |
|
whartung |
are client-focused apis in parallel with the resource ones? |
| 18:26 |
|
fuzzyhorns |
in parallel? |
| 18:27 |
|
whartung |
yea, do they overlap? i.e. clients -> client-focused apis -> data sources vs world -> resource api -> datasources |
| 18:27 |
|
fuzzyhorns |
my understanding is the bottom layer of apis are just getters and setters on some resources (where resources are basically models) |
| 18:27 |
|
fuzzyhorns |
they are meant to not overlap |
| 18:27 |
|
whartung |
ok |
| 18:28 |
|
whartung |
so then, another way to look at it |
| 18:28 |
|
whartung |
client -> models -> resource api -> data source |
| 18:28 |
|
fuzzyhorns |
so like client-focused apis would not be able to access data from a db, they would always make api calls to the resource api acting as a wrapper for the datasource |
| 18:28 |
|
fuzzyhorns |
mm, it is more like client -> business logic?? -> resource api (models) -> datasource |
| 18:29 |
|
fuzzyhorns |
models are kinda the rails parlance of the term, where you have containers of accessors and some minor low level object specific stuff? :/ |
| 18:29 |
|
whartung |
well no…it's more "we have a general purpose resource api", but "for our client demands, they like something a bit more tuned to their specific needs, so we will use that to augment the resource apis and make them more client friendly" |
| 18:30 |
|
whartung |
models are simply deserialized "stuff" in the native computing environemnt |
| 18:30 |
|
whartung |
for example |
| 18:30 |
|
fuzzyhorns |
why have a whole separate level of apps for this though? |
| 18:30 |
|
whartung |
resource api returns, say, XML. But your lcient just wants to work with properties or getters/setters, and reamin "xml ignornant" |
| 18:31 |
|
fuzzyhorns |
i dont follow, the clients would be negotiating their format types |
| 18:31 |
|
whartung |
because the layer is going to exist anyway. You're always going to have some serialization layer to get your data on to the wire. The client api can hide that layer from the client code. |
| 18:31 |
|
whartung |
would they? You sure about that? Are there really actually options to negotiate? |
| 18:31 |
|
fuzzyhorns |
yes but what is the advantage of that layer being an entire array of deployed apps? |
| 18:32 |
|
fuzzyhorns |
http has content negotiation, so, i think, yes? |
| 18:32 |
|
whartung |
the advnatage is to share that layer with your apps |
| 18:32 |
|
|
nkoza joined #rest |
| 18:32 |
|
fuzzyhorns |
what do you mean? |
| 18:32 |
|
whartung |
yes, it does have that capability, doesn't mean it would be used |
| 18:33 |
|
fuzzyhorns |
imo, all this does is say, oh, we get a uniform interface layer via http |
| 18:33 |
|
whartung |
I mean, you write one set of reusbale code (a library, what have) that your applications leverage, which makes working with the data in a more native format easier. reather than constantly marshalling in and out of the wire protocol. |
| 18:33 |
|
whartung |
that's very likely |
| 18:33 |
|
fuzzyhorns |
which we'd get all within the same app too |
| 18:34 |
|
fuzzyhorns |
i dont follow, maybe we're talking past each other lol |
| 18:34 |
|
whartung |
appreciate, REST is really hard. MOST applications do not need it's full capability and scope (witness RPC over HTTP via JSON/XML) |
| 18:35 |
|
fuzzyhorns |
idk, im curious if anyone else has opinions here :/ -- im not hearing a case that makes sense to me |
| 18:35 |
|
whartung |
so most applications do not go the extra mile (or several miles) for a fully REST, Resouce bases HATEOAS architecture |
| 18:35 |
|
whartung |
most applications simply are not big enough to be worth the effort |
| 18:35 |
|
fuzzyhorns |
a single app can deserialize from its datastore. abstracting over datastores via multiple apps, idk |
| 18:35 |
|
fuzzyhorns |
only big apps are worth hypermedia? |
| 18:36 |
|
fuzzyhorns |
huh you have a lot of assumptions i dont have yet, so youd need to really flesh those out for me with sources etc |
| 18:36 |
|
whartung |
the primary benefits of hypermedia are longevity, robustness to change, availability, etc. |
| 18:36 |
|
whartung |
but in order to get that, it takes a lot of work |
| 18:37 |
|
whartung |
compared to having a full time developer making random tweaks as "stuff" comes up in normal maintenance and development |
| 18:37 |
|
fumanchu |
fuzzyhorns: those all sounds like good questions for you dir of arch? |
| 18:37 |
|
fumanchu |
your* |
| 18:38 |
|
fuzzyhorns |
fumanchu: he is not very good at expressing himself :/ |
| 18:38 |
|
whartung |
if you expect to have a LOT of clients running a bunch of different versions, REST and HATEAOS make a lot of sense |
| 18:38 |
|
fuzzyhorns |
whartung: again you cant just state stuff like that to me without resource or source and expect it to have utility to me :/ it wont |
| 18:38 |
|
fuzzyhorns |
resource = reason lol |
| 18:38 |
|
whartung |
but if it's two branche offices talking to 100 users in an internal application, where you can just upgrade them all with a deploy…it's quite likely not worth the effort |
| 18:38 |
|
fuzzyhorns |
resource on the brain |
| 18:39 |
|
|
nkoza joined #rest |
| 18:39 |
|
fumanchu |
too bad :( he has reasons for those choices that are probably highly specific to your domain, which we can only guess at |
| 18:40 |
|
whartung |
and I can't summarize 30 years of dealing with computers and people and change and budgets and management in IRC. So, you just have to trust me -- REST is hard, REST is expensive, MOST people do not practice it beyond RPC, because RPC is "Good Enough" |
| 18:40 |
|
fuzzyhorns |
fumanchu: i dont see how the domain gives those reasons myself |
| 18:40 |
|
fuzzyhorns |
whartung: yeah no ol |
| 18:40 |
|
fumanchu |
I don't envy you that :/ |
| 18:40 |
|
fuzzyhorns |
whartung: sorry dude, i appreciate it is hard to express experiences, but that doesnt mean i take stuff on faith -- in this field, i am consciously trying to not do that anymore |
| 18:41 |
|
fuzzyhorns |
whartung: it has no utility to me to be told "well trust me", it has utility to tell me "well i see the distinctions as x and y" |
| 18:41 |
|
whartung |
the era we are in today is little different than were we were 25 years ago. Semantically, it's pretty much identical. It differs in details, but not dramatically |
| 18:42 |
|
sfisque |
fuzzyhorns i think what whartung is trying to convey is there is a tradeoff due to diminshing returns. any enterprise that wants to stay in business is not going to throw immense resources at a small app just to fulfill the spirit of REST or HATEAOS |
| 18:42 |
|
whartung |
yea, what he siad |
| 18:42 |
|
fuzzyhorns |
and still, nobody has managed to describe the tradeoffs :d |
| 18:42 |
|
sfisque |
time |
| 18:42 |
|
sfisque |
money |
| 18:42 |
|
whartung |
yes |
| 18:42 |
|
fuzzyhorns |
i guess this all counts as proof towards "rest is hard" lol |
| 18:42 |
|
sfisque |
personel |
| 18:43 |
|
sfisque |
enterprise is hard |
| 18:43 |
|
sfisque |
anyone can slap together a 100 line app and say "done" |
| 18:43 |
|
fuzzyhorns |
so REST and HATEOAS is inherently higher resource cost? |
| 18:43 |
|
fumanchu |
I did implement such a system at the previous company. There were components serving various user groups (analysts, admins, etc) that all talked to a centralized data service |
| 18:43 |
|
fuzzyhorns |
sfisque: indeed, though i think often, the real problem there is the invisible cost of shitty stuff |
| 18:43 |
|
fumanchu |
that was more for integration needs than anything else, so the various apps didn't end up implementing incompatible DB access code |
| 18:43 |
|
fuzzyhorns |
sfisque: which simply isnt accounted for, ime |
| 18:43 |
|
sfisque |
it's more than that |
| 18:44 |
|
sfisque |
requirements change, needs change, code becomes obsolete because workflows change |
| 18:44 |
|
fuzzyhorns |
fumanchu: this would not be a centralized data service, what the dir is recommending, that is part of what confuses/worries me |
| 18:44 |
|
fuzzyhorns |
sfisque: that is a distinct thing |
| 18:44 |
|
fuzzyhorns |
sfisque: i am talking technical debt |
| 18:44 |
|
whartung |
http://stackoverflow.com/questions/20335967/how-useful-important-is-rest-hateoas-maturity-level-3/20336307#20336307 |
| 18:44 |
|
fuzzyhorns |
sfisque: all code has a lifespan, it ages and dies |
| 18:44 |
|
sfisque |
are you trying to avoid it? or fix existing? |
| 18:44 |
|
whartung |
all code is technical debt |
| 18:45 |
|
fuzzyhorns |
whartung: lol no |
| 18:45 |
|
fumanchu |
sounds more like "let's move stored procedures up to HTTP" to me |
| 18:45 |
|
fuzzyhorns |
imo, no |
| 18:45 |
|
sfisque |
because if you;'re trying to avoid it, get in line. they've been trying to do that for over 50 years |
| 18:45 |
|
fuzzyhorns |
there's no avoiding it, it is not a different of kind, but of degree |
| 18:45 |
|
fumanchu |
but perhaps I lack detail |
| 18:46 |
|
sfisque |
and what whartung said is true gold. every line of code you write, is a maintenance footprint, whether you want to admit it or not |
| 18:46 |
|
fuzzyhorns |
technical debt != maintenance to me |
| 18:46 |
|
whartung |
no, it is fuzzyhorns, sorry if you don't agree. What's the key mantra people parrot all the time? "the more lines of code, the harder it is to maintain" thus the drive to different languages, abstractions, etc. No code has no mainteance. the more code, the more mainteance, and ALL of that gets folded in to the technical debt of the system. it ALL has to be understood and maintained and mastered and trained and learned…over and over and |
| 18:46 |
|
whartung |
again |
| 18:47 |
|
fuzzyhorns |
whartung: maintenance != technical debt to me |
| 18:47 |
|
sfisque |
GOAL!!! |
| 18:47 |
|
fuzzyhorns |
seriously yall? you dont consider there is any distinction there? |
| 18:47 |
|
sfisque |
YELLOW CARD |
| 18:47 |
|
whartung |
all code had momentum fuzzyhorns, good code, bad code, etc. |
| 18:47 |
|
fuzzyhorns |
to me all code is maintenance, because all writing is rewriting |
| 18:48 |
|
fuzzyhorns |
but some stuff you wont even rewrite, it is just shit lol |
| 18:48 |
|
whartung |
that's why you rewrite it. |
| 18:48 |
|
whartung |
to "un-shit" it |
| 18:48 |
|
sfisque |
what is the difference between rewrite and throw away/replace |
| 18:48 |
|
fuzzyhorns |
"wont even rewrite" != "will rewrite" |
| 18:48 |
|
sfisque |
i think we're at the hand waving and semantics point |
| 18:48 |
|
whartung |
so you can right "new shit" that someone will come along in 10 years and say "Man, this is shit" |
| 18:48 |
|
fuzzyhorns |
sfisque: we could we, would explain why everyone is so certain i am wrong lol |
| 18:49 |
|
whartung |
if I'm wrong, I've been wrong for 30 years |
| 18:49 |
|
sfisque |
i do not see it as 1/0 |
| 18:49 |
|
fuzzyhorns |
thirty years! thirty years!!! |
| 18:49 |
|
fuzzyhorns |
people can be wrong much longer than that, whartung |
| 18:49 |
|
sfisque |
but i'm a mathematician and absolutes only exist on paper |
| 18:49 |
|
fuzzyhorns |
absolutes are terribly inefficient anyway |
| 18:50 |
|
whartung |
I'm glad my experience seems to have value to you fuzzyhorns |
| 18:50 |
|
fuzzyhorns |
whartung: if it cant be communicated, it has only value to you |
| 18:50 |
|
fuzzyhorns |
such is life :/ |
| 18:50 |
|
whartung |
hard to communicate when you don't listen |
| 18:50 |
|
whartung |
you don't trust the source and you disagree with the content…not much I can do there |
| 18:50 |
|
fuzzyhorns |
you gave me some rhetoric, i told you "insufficient" |
| 18:51 |
|
fuzzyhorns |
it happens |
| 18:51 |
|
fuzzyhorns |
i dont disagree with the content, it is just unsupported accept by "well witness me" |
| 18:51 |
|
fuzzyhorns |
except* |
| 18:51 |
|
fuzzyhorns |
to me there's a difference between, a car runs basically as it should, and yes, must be slowly replaced part by part until the original no longer exists |
| 18:51 |
|
fuzzyhorns |
and making an entirely new vehicle because the old one blew up ;) |
| 18:52 |
|
|
quimrstorres joined #rest |
| 18:53 |
|
fuzzyhorns |
like you say in your post, "REST breeds complexity" |
| 18:53 |
|
fuzzyhorns |
this is a very strong, falsifiable (to some degree) claim |
| 18:53 |
|
fuzzyhorns |
and one that deserves more than "well ime" |
| 18:54 |
|
fuzzyhorns |
im not actually in here to be a huge prick will |
| 18:54 |
|
sfisque |
ok, but what are you in here for then? are you trying to discern something or just argue some points? |
| 18:55 |
|
sfisque |
and i mean that sincerely and not trolling |
| 18:55 |
|
whartung |
well, in my experience, unless it's a rocket ship, systems don't blow up. I've found the software is, well, "soft". I've found that it can be changed. I've changed the wheels on that running car while it's hurtling down the highway and hitting potholes. I'm in fact not a real big fan of rewrites. Once you're rewritten a few systems you learn that the grass is always greener but someone still mow it, and that pristine rewrites will end up |
| 18:55 |
|
whartung |
getting…rewritten. |
| 18:55 |
|
whartung |
the primary cause for systems to be obsolete is teh people that maintain them leave. The software itself is not the problem. The magnitude of the complexity that they manage is the problem. |
| 18:56 |
|
whartung |
back in the day, hardware moved fast enough, that yea, porting of that the 20 yr old NCR mainframe made a lot of sense. |
| 18:56 |
|
whartung |
today, we've been runing the same software for ever. Unix is unix…and looks like unix will be unix tomorrow as well. So THOSE fundamentals aren't changing for some time |
| 18:58 |
|
whartung |
hardware is gone as a denominator in system design for the vast majority of applciations. Hardware is pure commodity today. To the point where we make hardware out of thin air with vms, containers, docker, "hyper threads", what have you. |
| 18:58 |
|
whartung |
hardware is purely a WATTs problem today |
| 19:08 |
|
trygvis |
and network latency with all these new hipster client push apps mobile stuff |
| 19:08 |
|
trygvis |
hip hip |
| 19:19 |
|
|
warehouse13 joined #rest |
| 19:21 |
|
fuzzyhorns |
whartung: yeah im dealing with fighting a from scratch rewrite right now :/ |
| 19:21 |
|
fuzzyhorns |
sfisque: what i hope, is for evidence or reason lol, either from researchers (hoping some academics are here) or industry folks that have case studies essentially |
| 19:22 |
|
fuzzyhorns |
whartung: i STRONGLY agree with the "people leaving" is a problem |
| 19:22 |
|
fuzzyhorns |
whartung: i think software has a ton of hidden state: programmers |
| 19:23 |
|
sfisque |
fuzzyhorns "evidence or reason" of what? i know i pop in/out at various times, so it is unclear to me what you are trying to uncover, that's all |
| 19:23 |
|
fuzzyhorns |
sfisque: too general, it comes down to different claims about REST |
| 19:24 |
|
fuzzyhorns |
sfisque: like hartung claims REST breeds complexity |
| 19:24 |
|
fuzzyhorns |
sfisque: imo, that is opposite to the truth (because i see the human state of managing RPC as part of the cost) |
| 19:24 |
|
sfisque |
every architectural approach can breed complexity |
| 19:24 |
|
fuzzyhorns |
sfisque: but! our opinions can differ, so what can we look to, to find a more solid answer? |
| 19:25 |
|
fuzzyhorns |
sfisque: i disagree, entropy is distinct x) |
| 19:25 |
|
sfisque |
except maybe the bauhaus approach but this isnt 1930's germany |
| 19:25 |
|
fuzzyhorns |
i think that was 20s |
| 19:25 |
|
sfisque |
lasted into teh 30's iirc, before the nazi's forced them out |
| 19:25 |
|
fuzzyhorns |
makes sense |
| 19:26 |
|
sfisque |
that whole egalaterian thing kind of didnt mesh well :P |
| 19:27 |
|
fuzzyhorns |
oddly it never does with fascists |
| 19:28 |
|
fuzzyhorns |
have you ever seen such a rewrite succeed, whartung? (i havent but my career is much shorter than yours) |
| 19:37 |
|
|
vanHoesel joined #rest |
| 19:40 |
|
|
impl joined #rest |
| 19:44 |
|
impl |
so, I apologize in advance for my current ignorance... seems the REST world has moved on without me and now I'm playing catch up. is HAL still the way to go with JSON? it seems the most intuitive. |
| 19:45 |
|
trygvis |
HAL is still popular |
| 19:45 |
|
impl |
are there newer/better standards-track stuff? |
| 19:55 |
|
fuzzyhorns |
impl: what do you want to do? |
| 19:55 |
|
fuzzyhorns |
impl: HAL is a very simple hypermedia type, so the question is what sort of things do you want hypermedia to express for you |
| 19:56 |
|
fuzzyhorns |
impl: you may wanna look at json-api which has a lot of comm support too |
| 20:01 |
|
|
Left_Turn joined #rest |
| 20:22 |
|
|
mgomezch joined #rest |
| 20:24 |
|
|
Coldblackice joined #rest |
| 20:25 |
|
impl |
fuzzyhorns: cool, i'll take a look at that as well. my use case is really simple for this project (basically two entity resources + a search resource), but i'd sort of like something that i can use for future stuff as well rather than worrying about people having to implement multiple standards |
| 21:00 |
|
fuzzyhorns |
impl: search resource, have you looked at search specific types? slash, have you looked to see which types implement a search? :) a few do |
| 21:00 |
|
fuzzyhorns |
impl: usually called "queries" |
| 21:02 |
|
impl |
fuzzyhorns: it's not a typical search resource, it's actually for some geocoding stuff... so it basically just takes in a bunch of specific parameters (address, locality, administrative area(s), etc.) and the output is just one or two locations |
| 21:02 |
|
fuzzyhorns |
impl: looked at geojson? :) |
| 21:02 |
|
impl |
i have! i'm using it for boundaries already |
| 21:03 |
|
impl |
postgis makes it all easy with ST_AsGeoJSON |
| 21:04 |
|
fuzzyhorns |
oh neat! didnt know that |
| 21:04 |
|
fuzzyhorns |
impl: also i think that's not far off from a usual search |
| 21:05 |
|
impl |
yeah, i mean, it's simplified... like there's no options for pagination or sorting or anything like that |
| 21:05 |
|
impl |
in fact ideally it's just a redirect to a single resource, but i don't know how practical that is yet |
| 21:06 |
|
fuzzyhorns |
i mean, you can do that |
| 21:06 |
|
fuzzyhorns |
you can have locations?include=blah&blah&blah etc |
| 21:06 |
|
impl |
right |
| 21:06 |
|
fuzzyhorns |
but then return a single location |
| 21:06 |
|
impl |
i mean from the actual application standpoint, i don't know if it's sufficient to always return a single location |
| 21:07 |
|
impl |
people might need choices, as much as i hate giving them |
| 21:07 |
|
fuzzyhorns |
prob better to always return a collection or a single thing, otherwise too confusing imo |
| 21:07 |
|
fuzzyhorns |
you could, though, default it to one, but if there are other choices possible |
| 21:07 |
|
impl |
i might just make two resources, one that provides a list with confidences and one that's like "i'm feeling lucky" |
| 21:07 |
|
fuzzyhorns |
return a hypermedia control saying "also check these out if that one isnt enough" |
| 21:08 |
|
impl |
oh, i could do that too. that's not a bad idea. |
| 21:08 |
|
fuzzyhorns |
:) |
| 21:09 |
|
fuzzyhorns |
ill be curious how you end up crafting it |
| 21:09 |
|
fuzzyhorns |
time to go try and catch my commuter rail, good luck :) |
| 21:09 |
|
impl |
i already ran into an annoyance with HAL trying to create a hierarchy with multiple _embeddeds getting duplicated, so now i'm looking harder at JSON-API which doesn't appear to have that problem |
| 21:09 |
|
impl |
:{ |
| 21:09 |
|
impl |
thanks for the help though, i'll let you know how it goes :) |
| 21:09 |
|
fuzzyhorns |
i also like collection+json but it is oriented to collections |
| 22:26 |
|
|
ironChicken joined #rest |
| 22:27 |
|
|
cigarshark joined #rest |
| 22:31 |
|
|
vanHoesel joined #rest |
| 22:54 |
|
|
kevinswiber joined #rest |
| 23:11 |
|
|
kevinswiber joined #rest |
| 23:38 |
|
|
kevinswiber joined #rest |
| 23:48 |
|
|
kevinswiber joined #rest |
| 23:51 |
|
|
kevinswiber joined #rest |
