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