Time  Nick        Message
21:43 autrilla_   Other things could be sent too, for example the speed of a fan, the percentage of a window that's open, stuff like that
21:38 autrilla_   whartung, it depends on the device. For example, temperature probes would post temperatures
21:35 whartung    autrilla_: a) doesn't matter. That said, b) what are they POSTing?
21:31 autrilla_   I have a set of different embedded devices, and I want them to send information to my server, possibly via HTTP and RESTful web service. To what URL should each device post? Something like /device_id? Or maybe /device_type/device_id?
16:41 seanbrant   fumanchu_: makes sense
16:30 fumanchu_   that is: you did create a new resource; just because it isn't at its final state doesn't mean it doesn't exist
16:28 fumanchu_   let the "status" indicate the async nature
16:28 fumanchu_   yes, but I would recommend 201 instead of 202
16:22 seanbrant   As I need a resource that fetches async a remote list of repositories from say Github. Does this API make sense? https://gist.github.com/seanbrant/2c659e872dfe9788f8f2
14:04 trygvis     if you want to try to follow how RESTful architectures is supposed to be that is
14:03 trygvis     jsys: the URL is supposed to be opaque. what is important is how the user discovers the URL
13:52 jsys        Mine's simple:  TokenPayload identified by TokenId under /tokens/
13:51 jsys        trygvis: every*
13:51 jsys        trygvis: very API had no clue what their "resources" are.
13:51 jsys        trygvis: well my choice is more REST than any other API I saw today.
13:50 autrilla    I have a set of different embedded devices, and I want them to send information to my server, possibly via HTTP and RESTful web service. To what URL should each device post? Something like /device_id? Or maybe /device_type/device_id?
13:48 trygvis     maybe in your world, but this is REST and does certain assumptions
13:40 jsys        Heh, or rather.. "tokens"
13:40 jsys        Anyway I'll just call it "tokans"
13:39 jsys        trygvis: the fact the a service *client* is also a web site *server* is not important. But it has to be something. An app, a site, something.
13:39 jsys        trygvis: I can also do an HTTP call directly via AJAX, nothing changes
13:37 trygvis     rest and http mainly conserns itself about communication between a single client and a single (origin) server, not client -> server -> server
13:35 jsys        right
13:35 jsys        Rght
13:35 trygvis     as in a http server that does another http call to another service on behalf of a browser?
13:34 jsys        trygvis: if you have a service and some client consumes it, if I say "iOS client" I mean an iOS app that talks to the service; If I say "web client" I mean a web site that talks to the service.
13:33 trygvis     a site is normally a term used for a server of sorts, so I am really confused
13:33 * jsys      gives up
13:33 jsys        ironChicken: so high level I have to explain what a "site" is :P
13:32 ironChicken i love the way debates in this channel and so high level
13:32 trygvis     and by "site" you mean?
13:32 jsys        But nothing changes with a program
13:32 jsys        web client = site
13:32 trygvis     are you talking about a browser or a program?
13:32 jsys        trygvis: the web client has a session with the user. What's confusing about this.
13:32 trygvis     you're not making sense
13:31 trygvis     uhm, "session"?
13:31 jsys        trygvis: while the password doesn't
13:31 jsys        trygvis: however this is why it expires and has limited scope
13:31 jsys        trygvis: in the session
13:31 trygvis     "put" as in "store"
13:31 jsys        trygvis: put it?
13:30 trygvis     where do you expect to put this "token" you're talking about?
13:30 jsys        What is the name of a resource whose id is a token and its payload is credentials for a user?
13:30 jsys        So we're baxk where we started :P
13:30 trygvis     you can do as pdurbin said and replace a username/password with a persistent token, but you'd still use http auth to send it
13:29 jsys        trygvis: lets imagine a web client, the user signs in once. Where would the web client stuff the password, in plain text, so it can keep passing it to the services?
13:29 trygvis     why?
13:29 jsys        trygvis: that is obviously impossible.
13:29 trygvis     just send the username and password in every request
13:29 jsys        trygvis: what's the alternative
13:29 trygvis     and bad architecture
13:28 trygvis     creating sessions like that is not only bad REST, it is bad HTTP
13:28 jsys        trygvis: what's the alternative
13:28 trygvis     jsys: no, why do you need to create these tokens in the first place?
13:28 jsys        ironChicken: ok so you cll it "session"
13:28 trygvis     ironChicken: why would you do that if you already have a username and password? just use HTTP's built-in authentication?
13:27 jsys        trygvis: find a proper name for a resource, whose payload is "this user with those permissions" and its id is "the token used to authorize actions"
13:27 ironChicken jsys: > 201 Created; Location: /session/24395645 application/javascript {"id":"24395645",...}
13:27 trygvis     I don't understand what you're trying to do
13:26 jsys        But I don't know what to call that resource
13:26 jsys        And so /tokens is also kinda misleading.
13:26 jsys        I mean I could also call it /passwords and that would be confusing.
13:26 ironChicken jsys: < POST /session  application/json {"username":"..","password":".."}
13:26 jsys        I care because this is a communication issue.
13:26 trygvis     don't worry, nobody cares about the URL anyway
13:25 jsys        I mean that's not proper english :P
13:25 trygvis     why does your token expire?
13:25 jsys        Some call the resources /tokens but... a token is the *id* not the *payload
13:25 jsys        I'm not sure what to call them.
13:25 trygvis     that's one way to do it
13:25 jsys        pdurbin: thanks. My tokens expire and have limited scope so when I create a user I return an id, and then have a separate resource collection for tokens. Or such is the plan at least
13:23 pdurbin     jsys: we send back the token when the user is created. see http://irclog.greptilian.com/rest/2015-01-09#i_90891
13:21 trygvis     those APIs are probably not RESTful :)
13:19 jsys        I browsed and browsed various APIs, they all do it differently.
13:19 jsys        I pass user/pass (or other auth info) and get back token id
13:19 jsys        Folks how should an endpoint behave for *generating* tokens
11:51 Karthi      Hi i want to know how to make a secondary webserverice url in app ?