Time Nick Message
21:21 whartung I'm not intimate enough with OpnID to say when the enforcement happens, and it depends on what you mean by "forged", but to a point it's "in there somewhere".
21:19 Doc-Saintly Does the whole OAuth / OpenID pipeline handle making sure that the token hasen't been forged? Or does my back-end have to do that by auth'ing with what's in the token and looking up the details.
21:19 Doc-Saintly so I can authenticate them, and authorize them to make moves, and then pass this token to the REST service which would just look at the name of the player, and that they can make moves, and then do the rest without looking things up - yes?
21:18 Doc-Saintly So I can call "makeMove" for a player and it makes the move they specify. but, now I need to secure it and only let registered players make moves, and only on their account - obviously.
21:18 whartung but at that point, it's 99.9999% safe to cache the higher level meta data (name, email, roles)
21:18 Doc-Saintly True. Well, basically I've made a round based game via REST service.
21:17 whartung I don't know where in the workflow you get the actual user id for the requestor
21:17 whartung give it some reasonable time to live (10s, 1m, 10m, whatever)
21:17 Doc-Saintly Javascript Web Token
21:17 whartung but "yes", basically
21:17 whartung JWT?
21:15 Doc-Saintly JWT*
21:15 Doc-Saintly or would I not trust the roles in the KWT?
21:15 Doc-Saintly hmmm, so I suppose in the JWT I could store the roles that are important, and just reference the token (because I trust it) and not go look up the user and see their roles each time?
21:14 whartung *saw
21:14 whartung "yea, we just say this guy 4 microseconds ago..."
21:14 whartung so, in truth most folks will cache things like that locally.
21:14 whartung caching makes things "less expensive:
21:14 Doc-Saintly So, is it not done commonly?
21:14 whartung if you pay attention, EVERYTHING in REST is expensive.
21:13 whartung :)
21:13 whartung it is :0
21:13 Doc-Saintly seems expensive :S
21:13 whartung yea the rest service looks up the info each time.
21:13 whartung Oh, ok.
21:11 Doc-Saintly (Or OAuth 2 flows + authentication)
21:11 Doc-Saintly OpenID Connect
20:53 whartung what's OIDC?
20:51 Doc-Saintly What is the design pattern for REST with OIDC? Does the client get the auth token and pass it along to the REST service each time, and the REST service looks up the user information each time?
18:49 sfisque i bet
18:48 whartung SearchRequset is a hoot!
18:48 whartung THere's Apache DS, but that's stuff is to tight it's impossible to dig it out -- and we EMPLOY a committer to the project!
18:48 sfisque atomic types are trivial from what i remember. it's the complex types that can trip up
18:48 sfisque aye. the issue gets dicey when you get blocks that have contiuations (like for large blobs) and stuff
18:48 whartung I did a good effort to look
18:48 whartung si
18:47 fumanchu so many libs that offer to save dev time but cost equally in integration time and then add poor performance on top
18:47 whartung but the BERs don't know that
18:47 whartung most of the LDAP constructs are just seuqneces ibehind app tags and context tags
18:47 sfisque aye. back in the day i looked at leveraging a library. i'll see if i can recover the reference (time to dig back 15 years)
18:47 whartung they don't read the sequences easily, I might gain a free octet string reader -- Ooh! there's time saved!
18:46 whartung once I have that, I have the basic tokenizer ANYWAY
18:46 whartung the Sun one requires a BUFFER, not a stream, so I have to decode the stream myself anyway.
18:45 whartung BouncyCastle has a stream decoder, and it's not particularly useful.
18:45 whartung Sun has a basic BER decoder, and it's not particularly useful.
18:45 sfisque :P
18:45 sfisque i think at&t has a job opening for you
18:45 * sfisque smacks whartung for reinventing the square wheel
18:44 whartung no, no need. I figured out how to read a length and decode the tag.
18:44 sfisque ?
18:44 sfisque at the very least
18:44 whartung "thanks"
18:44 sfisque so i guess you're leveraging a lib to lex the stream?
18:44 whartung SEQEUNCE APPLICATION <BLOB>
18:43 whartung they can't give me a reasonable DOM without LDAP context.
18:43 sfisque ok fair enough
18:43 whartung that's what parsing is -- interpeting tokens :)
18:43 sfisque any good ber lib will parse and hand you a tree and then you just need to descend and interpret
18:42 whartung <thing> <length> <stuff>
18:42 sfisque true, but no need to do parsing, just need to interpret the tokens generated from a ber library
18:42 whartung the basic decoding isnt difficult
18:42 whartung with all the Application and CHOICEs
18:41 whartung BER != LDAP tho
18:41 sfisque you know there are several BER libraries available, right?
18:41 whartung BER yo!
18:41 whartung wire protocol
18:41 sfisque for query strings or for the wire protocol?
18:40 whartung I've been writing an LDAP parser past week.
18:39 sfisque live and learn
18:39 sfisque i kick myself for never donating the directory server i wrote back in '99 as a reference impl for jndi
18:38 sfisque i forgot they subsumed derby
18:38 sfisque eventually it did, yeah
18:37 whartung and the JDK bundles Derby :D
18:37 sfisque aye
18:37 whartung JAX-WS, XML...
18:37 whartung yes, but that's one of the very few.
18:36 sfisque <cough> jdbc </cough>
18:36 sfisque au contraire
18:36 whartung but I've not used it
18:36 whartung JDK isn't really known for just bundleing interfaces
18:36 whartung oh, I think it has an operational implementation
18:36 sfisque @attr_name
18:36 sfisque aye that's xpath
18:35 whartung the @name are attributes
18:35 sfisque quick question. i know java 8 bakes json api into the jdk, does it also bundle an impl or is it just the api? thinking of switching project to 8
18:35 whartung I mean, they even converted the name spaces lol
18:35 sfisque second pair of eyes wins!
18:35 whartung have fun coaxing Jackson or GSON to serilaize this stuff lol
18:34 sfisque :-)
18:34 sfisque thx
18:34 sfisque that makes sense
18:34 whartung yes
18:34 sfisque oh so in this case $ constitutes "body" attribute
18:34 whartung it's a crummy xml to json converter
18:34 whartung no, because it allow content
18:34 sfisque right
18:34 sfisque and since xml allows N many of the same tag
18:34 whartung <version>123</version> == "version" : {"$":123}
18:33 sfisque AH
18:33 whartung it's XML converted to JSON :)
18:33 whartung this isn't json
18:33 whartung {"net":{"@xmlns":{
18:33 whartung oic
18:33 whartung right
18:33 sfisque aye
18:33 sfisque right, i guess why bother doing that when they could just do attribute : value
18:33 whartung why they chose to use a $ is a curious question
18:33 whartung all seem single valued.
18:32 whartung endAddrees, handle, name, description
18:32 whartung well, here is seems they're used for single valued properties
18:32 sfisque yes, but not sure if it means anything interesting, and how would that be mapped in say, java where "$" has special treatment (innerclass delimiter)
18:31 whartung apparently "@" is valid as well
18:31 whartung "doesn't mean anything"
18:31 whartung $ is a valid attribute characeter, like _, right?
18:30 sfisque e.g. if you hit this endpoint, you see a record that lis littered with "$" attribute names: http://whois.arin.net/rest/ip/75.75.75.75.json
18:28 sfisque question about json encoding. what does it mean if an endpoint returns a record with "$" as attribute name?
16:46 whartung I think I have that book at home...
16:06 fumanchu and frankly how to communicate it better
16:06 fumanchu foist: REST itself is an architectural style and doesn't really change. But the "materials" do and people continue to learn things about how to implement REST for different needs.
15:51 fission6 anyone here ever work with an API gateway
15:47 foist REST does not seem like something that is subject to change.
15:47 foist Have things really changed so much that there’s a whole new book required to describe modern techniques and knowledge?
15:46 fumanchu oo, and the former is now a free download: http://www.restfulwebapis.org/rws.html
15:45 foist Great, will try to fit that into my schedule.
15:43 fumanchu ah, I see mamund contributed to its successor: http://www.restfulwebapis.org/
15:42 fumanchu Richardson/Ruby is often recommended
15:42 foist s/why/how
15:42 fumanchu then I'd start with the how and that will give you some context to understand the why
15:42 foist What’s a good book on the why?
15:41 foist I’m pretty autonomous in this effort.
15:41 fumanchu only if nobody above you knows why ;)
15:40 foist Should one start with the why?
15:40 fumanchu Fielding's paper is why. There are lots of books on how.
15:39 foist Is there a book out there that covers REST fundamentals in great depth? Or is Roy Fielding’s paper pretty much the definitive resource?
15:39 fumanchu the thing to think about is how to communicate to the client that a POST to workers/1/locations is desirable and when/why
15:38 foist fumanchu: great. Thanks.
15:38 foist Is that wrong or bad in some way?
15:38 fumanchu that's no problem. it's totally up to the server to return what it wants (even a 404 Not Found or 405 Method Not Allowed) for any URL in its domain
15:32 foist sfisque: what if I want a POST access point at /workers/1/locations, but do not want to expose /workers for a GET?
15:27 sfisque npnp. be well
15:27 foist Thanks, sfisque. I’ll try to run with that.
15:26 foist Yes, I understand.
15:25 sfisque that's a kind of obtuse example, but i hope you get what i'm trying to convey
15:23 sfisque likewise, those two uri's could return different types even though they are both "worker" uri's. one could return personal information (like an HR system endpoint) and the other one could return timecard info (payroll system endpoint)
15:21 sfisque basically a uri indicates a view into your system, not the "type" of the return. essentially, you can have many endpoints that return the same type, so the uri is not a type, but a view that returns a particular type. this may appear trivial, but failing to keep that in mind can become a trap. basically just because i can obtain a worker at uri x/y/z/worker does not mean i cannot obtain a worker at a/b/c/d/worker. both e
15:19 foist Appreciate the help :)
15:19 sfisque bah, i typed up a bunch of stuff and adium barfed.. i'll try to retype it
15:16 foist Can you elaborate on "don't mix address (uri) with type."
15:15 sfisque locations 1 is the context for workers 2
15:15 sfisque i dislike the world "filtering" because it gets used in a lot of different contexts and means different things
15:15 foist Worker 2 is context for the location: /locations/1/workers/2?
15:14 sfisque yes
15:14 foist Filtering, you mean?
15:14 foist What is a culling mechanism?
15:14 sfisque query params are culling mechanisms
15:14 sfisque uri component
15:13 foist They are types when accessed as the bare URI, and are context when provided as a query param?
15:13 sfisque similar to ldap or any directory service
15:13 sfisque yes. that is the nature of any hierarchical system
15:13 foist They are both types and context?
15:12 sfisque they are, but they are "context"
15:12 sfisque so you don't have to think of them existing at a single uri. they can exists at many uri's depending on context
15:12 foist but /workers, /log, /locations are the URIs
15:12 sfisque in your example, workers, logs, and locations are "types"
15:11 foist sorry, what does “type” mean in this context?
15:11 sfisque your context dictates the result not the type. don't mix address (uri) with type. you can store the same "type" at different locations. what the locations dictate is a view into your system that can be acted on (put, del, post, etc.)
15:09 sfisque yes
15:09 foist In that case would /workers/1/locations/5/logs also seem appropriate?
15:09 sfisque yes
15:09 sfisque blah/logs?params=bleh == logs in teh whole with some culling aspects vs /blah/workers/blargh/logs?params=blooey == logs belonging to blargh with some culling aspects
15:08 foist sfisque: so do you mean both /logs along with /workers/1/logs?
15:07 sfisque that's the beauty of the hypertext world, context :-)
15:06 sfisque that would seem to make the most sense to me
15:06 foist You’re saying represent all three collections as top level end-points along with filtering in each one?
15:06 sfisque wouldnt you treat them as both top level AND nested. conceivably you could have an endpoint that represented logs "in the whole", vs "logs contextually belonging to a parent"
15:06 foist or /locations?worker=foist
15:04 saml /logs?location=berlin&worker=foist
15:04 saml you can filter logs by location or workers.. and vice versa
15:03 saml so you have three collections /logs, /locations, /workers
15:03 foist /locations, no?
15:03 foist But sometimes a location may exist with out a log.
15:02 saml /logs
15:02 foist I do need to be able to retrieve all locations, irrespective of whether the location has any logs.
15:01 saml so those information can be in representation. doesn't have to be in url
15:01 foist saml: yes, it certainly would.
15:00 saml foist, i'd think representation of /logs/1 will contain links to worker and location.
14:59 saml not much thought
14:59 fission6 curious if you had more thoughts
14:59 fission6 computer shut down
14:59 fission6 sorry saml you there
14:55 foist For instance, I have workers, logs, and locations. Workers create logs at locations. Should it be /workers/1/locations/23/logs/? Or /locations/23/logs/, or just /logs/?
14:54 foist I have a hard time deciding whether to represent something as a nested resource or as a top-level resource. Is there some guideline for this?
14:37 saml yah i'd just delete node.js platform
14:31 fission6 its two different platforms
14:31 fission6 i think y ou are thining of different api vcersions
14:30 saml just let your boss know all new features will be in v2 only. v1 will be frozen as is and depreacated.
14:30 saml if you want to add new feature to v1.. you need to work more
14:30 saml why not just keep v1 running as is? and release v2... and let clients change to v2 in a year or two.. deprecate v1.
14:29 saml everything works fine currently right?
14:29 saml if you only have control on v1 and v2, and not clients.. you don't have many choices
14:28 fission6 saml - thats the plan but the tech side is scared that client swill not want to make code changes and that it could be easier to introduce a gateway to map old API calls to the new ones
14:28 saml usually, api design goes hand in hand with client development
14:27 fission6 saml — well thats my main point to is hey, a compatability layer *Could* work but we need to focus on building v2 first, can’t map shit without something to map too
14:27 saml so, finish v2. migrate clients to v2. kill v1.
14:27 fission6 nope, v1 stays v2 is being built, lots of applications using v1 which is SOAP, we need to migrate to v2 —remeber v2 is hitting a while new product
14:27 saml i'd just finish v2. make it stable. then worry about client migration. client migration can be done in the form of rewriting v1. or update each client to use v2.
14:26 saml you need to rewrite v1 in addition to writing v2
14:25 fission6 some assumptions include, that there is an api call which makes in both versions for starters
14:25 saml so you want to keep v1. but v1 uses v2
14:25 fission6 to me thats a very idialogogy assumption that it would be that seamless
14:25 fission6 When we go to miugrate the clients to the new system, we are getting a lot of pushback around why do we need to migrate the applications vs translate their calls to the new system through a compatapibily layer / soap->rest gateway
14:24 fission6 app form on the old system. the new platform will have a RESTful API exposed as well for certain functionality, some overlaps with v1 some does not.
14:23 fission6 we are building a new platform with many enhancements and a new UI to do a lot things previously in
14:23 fission6 so the old platform has many custome applications built around it for clients which use api v1.
14:23 saml are you asking weather v2 can use v1 or not?
14:23 fission6 ok
14:22 fission6 they are two seperate platforms that do things a bit different but focus on marketing
14:22 saml doesn't matter. just two different apis
14:22 fission6 well they aren;t versions
14:22 saml let's call the new v2
14:22 saml let's call it v1
14:22 fission6 we have a new system we are building which offers a lot of functionality the old system did not
14:22 fission6 we have an old system which is SOAP based
14:22 fission6 so let me try to explain
14:21 saml or still keep SOAP for legacy clients.. etc
14:21 saml do you want to replace SOAP with REST?
14:17 fission6 I am trying ot understand the ideal use case to use a SOAP->REST translation service and see if it actually lines up with our situation
14:17 fission6 basicallt in a position where we have a bunch of current SOAP services, we have a new platform where we are building REST APIs, the tech team is making a case to use a translation service to translate SOAP to REST. The issue I have is that its not nessarily a one to one mapping in API endpoints available and the two systems are fundementally different.
14:17 fission6 Hello, i am faced with the following
13:47 angular_mike jackalista: sorry, what is spring data jpa?
13:40 jackalista I like that data access layer for reasons like that :)
13:39 jackalista allowed us to set a page size and then page throught results, etc. works pretty nicely and easy impl
13:38 jackalista mostly unchanged
13:38 jackalista not sure if this is helpful, but what we did was to take the pagination exposed by spring data jpa and expose it via services
13:38 angular_mike jackalista: oh?
13:37 jackalista spring data jpa infra gives you current page number out of total number of pages and page size, I found that mostly sufficient
13:30 angular_mike for paginated resource item listing is it better to implement a `count` method, or include total number of items in the responses related to the resource?
10:32 trygvis yeah