Time  Nick         Message
10:32 trygvis      yeah
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?
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:38 angular_mike jackalista: oh?
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 jackalista   mostly unchanged
13:39 jackalista   allowed us to set a page size and then page throught results, etc.  works pretty nicely and easy impl
13:40 jackalista   I like that data access layer for reasons like that :)
13:47 angular_mike jackalista: sorry, what is spring data jpa?
14:17 fission6     Hello, i am faced with the following
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     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:21 saml         do you want to replace SOAP with REST?
14:21 saml         or still keep SOAP for legacy clients.. etc
14:22 fission6     so let me try to explain
14:22 fission6     we have an old system which is SOAP based
14:22 fission6     we have a new system we are building which offers a lot of functionality the old system did not
14:22 saml         let's call it v1
14:22 saml         let's call the new v2
14:22 fission6     well they aren;t versions
14:22 saml         doesn't matter. just two different apis
14:22 fission6     they are two seperate platforms that do things a bit different but focus on marketing
14:23 fission6     ok
14:23 saml         are you asking weather v2 can use v1 or not?
14:23 fission6     so the old platform has many custome applications built around it for clients which use api v1.
14:23 fission6     we are building a new platform with many enhancements and a new UI to do a lot things previously in
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: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:25 fission6     to me thats a very idialogogy assumption that it would be that seamless
14:25 saml         so you want to keep v1. but v1 uses v2
14:25 fission6     some assumptions include, that there is an api call which makes in both versions for starters
14:26 saml         you need to rewrite v1 in addition to writing v2
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: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         so, finish v2. migrate clients to v2. kill v1.
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:28 saml         usually,  api design goes hand in hand with client development
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:29 saml         if you only have control on v1 and v2, and not clients.. you don't have many choices
14:29 saml         everything works fine currently right?
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:30 saml         if you want to add new feature to v1.. you need to work more
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:31 fission6     i think y ou are thining of different api vcersions
14:31 fission6     its two different platforms
14:37 saml         yah i'd just delete node.js platform
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: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:59 fission6     sorry saml you there
14:59 fission6     computer shut down
14:59 fission6     curious if you had more thoughts
14:59 saml         not much thought
15:00 saml         foist, i'd think representation of /logs/1  will contain links to worker and location.
15:01 foist        saml: yes, it certainly would.
15:01 saml         so those information can be in representation. doesn't have to be in url
15:02 foist        I do need to be able to retrieve all locations, irrespective of whether the location has any logs.
15:02 saml         /logs
15:03 foist        But sometimes a location may exist with out a log.
15:03 foist        /locations, no?
15:03 saml         so you have three collections  /logs, /locations, /workers
15:04 saml         you can filter logs by location or workers.. and vice versa
15:04 saml         /logs?location=berlin&worker=foist
15:06 foist        or /locations?worker=foist
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        You’re saying represent all three collections as top level end-points along with filtering in each one?
15:06 sfisque      that would seem to make the most sense to me
15:07 sfisque      that's the beauty of the hypertext world, context :-)
15:08 foist        sfisque: so do you mean both /logs along with /workers/1/logs?
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:09 sfisque      yes
15:09 foist        In that case would /workers/1/locations/5/logs also seem appropriate?
15:09 sfisque      yes
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:11 foist        sorry, what does “type” mean in this context?
15:12 sfisque      in your example, workers, logs, and locations are "types"
15:12 foist        but /workers, /log, /locations are the URIs
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 sfisque      they are, but they are "context"
15:13 foist        They are both types and context?
15:13 sfisque      yes.  that is the nature of any hierarchical system
15:13 sfisque      similar to ldap or any directory service
15:13 foist        They are types when accessed as the bare URI, and are context when provided as a query param?
15:14 sfisque      uri component
15:14 sfisque      query params are culling mechanisms
15:14 foist        What is a culling mechanism?
15:14 foist        Filtering, you mean?
15:14 sfisque      yes
15:15 foist        Worker 2 is context for the location: /locations/1/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 sfisque      locations 1 is the context for workers 2
15:16 foist        Can you elaborate on "don't mix address (uri) with type."
15:19 sfisque      bah, i typed up a bunch of stuff and adium barfed.. i'll try to retype it
15:19 foist        Appreciate the help :)
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: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:25 sfisque      that's a kind of obtuse example, but i hope you get what i'm trying to convey
15:26 foist        Yes, I understand.
15:27 foist        Thanks, sfisque. I’ll try to run with that.
15:27 sfisque      npnp.  be well
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: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:38 foist        Is that wrong or bad in some way?
15:38 foist        fumanchu: great. Thanks.
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: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:40 fumanchu     Fielding's paper is why. There are lots of books on how.
15:40 foist        Should one start with the why?
15:41 fumanchu     only if nobody above you knows why ;)
15:41 foist        I’m pretty autonomous in this effort.
15:42 foist        What’s a good book on the why?
15:42 fumanchu     then I'd start with the how and that will give you some context to understand the why
15:42 foist        s/why/how
15:42 fumanchu     Richardson/Ruby is often recommended
15:43 fumanchu     ah, I see mamund contributed to its successor: http://www.restfulwebapis.org/
15:45 foist        Great, will try to fit that into my schedule.
15:46 fumanchu     oo, and the former is now a free download: http://www.restfulwebapis.org/rws.html
15:47 foist        Have things really changed so much that there’s a whole new book required to describe modern techniques and knowledge?
15:47 foist        REST does not seem like something that is subject to change.
15:51 fission6     anyone here ever work with an API gateway
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.
16:06 fumanchu     and frankly how to communicate it better
16:46 whartung     I think I have that book at home...
18:28 sfisque      question about json encoding.  what does it mean if an endpoint returns a record with "$" as attribute name?
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/
18:31 whartung     $ is a valid attribute characeter, like _, right?
18:31 whartung     "doesn't mean anything"
18:31 whartung     apparently "@" is valid as well
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:32 whartung     well, here is seems they're used for single valued properties
18:32 whartung     endAddrees, handle, name, description
18:33 whartung     all seem single valued.
18:33 whartung     why they chose to use a $ is a curious question
18:33 sfisque      right, i guess why bother doing that when they could just  do attribute : value
18:33 sfisque      aye
18:33 whartung     right
18:33 whartung     oic
18:33 whartung     {"net":{"@xmlns":{
18:33 whartung     this isn't json
18:33 whartung     it's XML converted to JSON :)
18:33 sfisque      AH
18:34 whartung     <version>123</version> == "version" : {"$":123}
18:34 sfisque      and since xml allows N many of the same tag
18:34 sfisque      right
18:34 whartung     no, because it allow content
18:34 whartung     it's a crummy xml to json converter
18:34 sfisque      oh so in this case $ constitutes "body" attribute
18:34 whartung     yes
18:34 sfisque      that makes sense
18:34 sfisque      thx
18:34 sfisque      :-)
18:35 whartung     have fun coaxing Jackson or GSON to serilaize this stuff lol
18:35 sfisque      second pair of eyes wins!
18:35 whartung     I mean, they even converted the name spaces lol
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     the @name are attributes
18:36 sfisque      aye that's xpath
18:36 sfisque      @attr_name
18:36 whartung     oh, I think it has an operational implementation
18:36 whartung     JDK isn't really known for just bundleing interfaces
18:36 whartung     but I've not used it
18:36 sfisque      au contraire
18:36 sfisque      <cough> jdbc </cough>
18:37 whartung     yes, but that's one of the very few.
18:37 whartung     JAX-WS, XML...
18:37 sfisque      aye
18:37 whartung     and the JDK bundles Derby :D
18:38 sfisque      eventually it did, yeah
18:38 sfisque      i forgot they subsumed derby
18:39 sfisque      i kick myself for never donating the directory server i wrote back in '99 as a reference impl for jndi
18:39 sfisque      live and learn
18:40 whartung     I've been writing an LDAP parser past week.
18:41 sfisque      for query strings or for the wire protocol?
18:41 whartung     wire protocol
18:41 whartung     BER yo!
18:41 sfisque      you know there are several BER libraries available, right?
18:41 whartung     BER != LDAP tho
18:42 whartung     with all the Application and CHOICEs
18:42 whartung     the basic decoding isnt difficult
18:42 sfisque      true, but no need to do parsing, just need to interpret the tokens generated from a ber library
18:42 whartung     <thing> <length> <stuff>
18:43 sfisque      any good ber lib will parse and hand you a tree and then you just need to descend and interpret
18:43 whartung     that's what parsing is -- interpeting tokens :)
18:43 sfisque      ok fair enough
18:43 whartung     they can't give me a reasonable DOM without LDAP context.
18:44 whartung     SEQEUNCE APPLICATION <BLOB>
18:44 sfisque      so i guess you're leveraging a lib to lex the stream?
18:44 whartung     "thanks"
18:44 sfisque      at the very least
18:44 sfisque      ?
18:44 whartung     no, no need. I figured out how to read a length and decode the tag.
18:45 * sfisque    smacks whartung for reinventing the square wheel
18:45 sfisque      i think at&t has a job opening for you
18:45 sfisque      :P
18:45 whartung     Sun has a basic BER decoder, and it's not particularly useful.
18:45 whartung     BouncyCastle has a stream decoder, and it's not particularly useful.
18:46 whartung     the Sun one requires a BUFFER, not a stream, so I have to decode the stream myself anyway.
18:46 whartung     once I have that, I have the basic tokenizer ANYWAY
18:47 whartung     they don't read the sequences easily, I might gain a free octet string reader -- Ooh! there's time saved!
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     most of the LDAP constructs are just seuqneces ibehind app tags and context tags
18:47 whartung     but the BERs don't know that
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:48 whartung     si
18:48 whartung     I did a good effort to look
18:48 sfisque      aye.  the issue gets dicey when you get blocks that have contiuations (like for large blobs) and stuff
18:48 sfisque      atomic types are trivial from what i remember.  it's the complex types that can trip up
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 whartung     SearchRequset is a hoot!
18:49 sfisque      i bet
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?
20:53 whartung     what's OIDC?
21:11 Doc-Saintly  OpenID Connect
21:11 Doc-Saintly  (Or OAuth 2 flows + authentication)
21:13 whartung     Oh, ok.
21:13 whartung     yea the rest service looks up the info each time.
21:13 Doc-Saintly  seems expensive :S
21:13 whartung     it is :0
21:13 whartung     :)
21:14 whartung     if you pay attention, EVERYTHING in REST is expensive.
21:14 Doc-Saintly  So, is it not done commonly?
21:14 whartung     caching makes things "less expensive:
21:14 whartung     so, in truth most folks will cache things like that locally.
21:14 whartung     "yea, we just say this guy 4 microseconds ago..."
21:14 whartung     *saw
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:15 Doc-Saintly  or would I not trust the roles in the KWT?
21:15 Doc-Saintly  JWT*
21:17 whartung     JWT?
21:17 whartung     but "yes", basically
21:17 Doc-Saintly  Javascript Web Token
21:17 whartung     give it some reasonable time to live (10s, 1m, 10m, whatever)
21:17 whartung     I don't know where in the workflow you get the actual user id for the requestor
21:18 Doc-Saintly  True. Well, basically I've made a round based game via REST service.
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  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: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: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: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".