| Time |
S |
Nick |
Message |
| 00:45 |
|
|
fuzzyhorns joined #rest |
| 01:27 |
|
|
philbot joined #rest |
| 01:27 |
|
|
Topic for #rest is now #rest REpresentational State Transfer | logs: http://irclog.greptilian.com/rest/today | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer |
| 01:30 |
|
|
pdurbin joined #rest |
| 02:37 |
|
|
Phanes joined #rest |
| 02:37 |
|
Phanes |
ahhh im so glad this channel exists |
| 02:38 |
|
Phanes |
id like to have one of my api functions get multiple http requests from multiple 3rd party hosts |
| 02:39 |
|
Phanes |
but im not really sure how to handle that as it will make the rest call very slow |
| 02:39 |
|
Phanes |
in one of the functions its connecting to an irc server and running a command |
| 02:39 |
|
Phanes |
so obviously there are alot of moving parts there, how do you account for the time factor? |
| 03:23 |
|
|
ShekharReddy joined #rest |
| 03:36 |
|
|
fuzzyhorns joined #rest |
| 05:38 |
|
|
fuzzyhorns joined #rest |
| 06:07 |
|
|
bluezone joined #rest |
| 06:39 |
|
|
fuzzyhorns joined #rest |
| 07:15 |
|
|
Tomatosoup- joined #rest |
| 07:43 |
|
|
wsieroci joined #rest |
| 08:22 |
|
|
wsieroci joined #rest |
| 08:40 |
|
|
fuzzyhorns joined #rest |
| 09:28 |
|
|
wsieroci joined #rest |
| 09:48 |
|
|
cvander joined #rest |
| 10:34 |
|
|
fuzzyhorns joined #rest |
| 10:43 |
|
|
krs93 joined #rest |
| 12:02 |
|
pdurbin |
Phanes: are you sure it will be slow? Maybe it'll be fine. |
| 12:08 |
|
|
k_j joined #rest |
| 12:24 |
|
Phanes |
pdurbin, the IRC trigger i know will be as there's a scheduled delay |
| 12:25 |
|
Phanes |
one automation being triggered i know takes between 3-5 minutes |
| 12:44 |
|
pdurbin |
Phanes: maybe your REST endpoint can return "The long-running job has begun. You can query the status of the long-running job by doing a GET on id 12345." |
| 12:46 |
|
Phanes |
oh that's interesting |
| 12:46 |
|
Phanes |
is that restful? |
| 12:46 |
|
Phanes |
as it is technically dealing with states at that point |
| 12:52 |
|
pdurbin |
I'm not an authority on what is RESTful or not. It's practical. |
| 13:06 |
|
Phanes |
in all fairness the 'stateness' there is in the payload and not the api itself, but neither am i |
| 14:22 |
|
|
fuzzyhorns joined #rest |
| 14:54 |
|
|
Tomatosoup- joined #rest |
| 16:09 |
|
|
vishnurao joined #rest |
| 16:15 |
|
mamund |
Phanes: this is about HTTP, not REST so you can focus on the HTTP spec for some xample solutions. |
| 16:16 |
|
mamund |
check out HTTP status code "202 Accepted" this code tells the client, "Yes, i started working on your request. let me get back to you soon." |
| 16:17 |
|
mamund |
then check out subbu allamaraju's book "RESTful Web Services Cookbook" for a couple patterns to implementing 202 w/ callbacks or pings to get status updates on the work. |
| 16:18 |
|
mamund |
also, on the server implementation side (not HTTP now, just code) look into whether you can use async processing to paraellel the calls. that will cut down on the wait time. |
| 16:19 |
|
mamund |
finally, chekc out whether the callsyou are making can be cached. if yes, then you can cut down on subsequent calls to the same resource. this is an optimization but might come in handy. |
| 16:24 |
|
|
wsieroci joined #rest |
| 16:52 |
|
|
graste joined #rest |
| 17:18 |
|
|
qwick joined #rest |
| 17:29 |
|
|
qwick joined #rest |
| 17:32 |
|
qwick |
Hello all, |
| 17:32 |
|
qwick |
i am working on a proxy server,where every route corresponds to a specific route on backend. |
| 17:32 |
|
qwick |
The rest api provided by backend is already documented. |
| 17:32 |
|
qwick |
Do people generally generate documentation for proxy servers(in my case)? |
| 17:52 |
|
|
Sna4x81 joined #rest |
| 18:42 |
|
mamund |
qwick: if you're offering an interface (API) you should offer _some_ documentation for it. |
| 19:47 |
|
|
sfdebug joined #rest |
| 19:48 |
|
sfdebug |
hi, can anyone tell me or give me an article or book that can be very direct to the theme REST? I want to understand the main principles... |
| 20:03 |
|
|
wsieroci joined #rest |
| 20:08 |
|
mamund |
sfdebug: i recommend the book "RESTful Web API" by Leonard Richardson |
| 20:08 |
|
mamund |
there are a handful of others i recommend and i put them together in a list for InfoQ called the "REST-y Reader" |
| 20:09 |
|
mamund |
https://www.infoq.com/articles/rest-reading-list |
| 20:09 |
|
mamund |
others here may have their favorites to recommend, too. |
| 20:45 |
|
|
tonyacunar joined #rest |
| 20:46 |
|
Sna4x81 |
I need some API design help. I have a suite of APIs that work great--they're fast and easy to maintain--but I suppose I didn't implement PUT correctly in that PUT let's the user make partial updates right now. That doesn't conform to REST, right? |
| 20:46 |
|
tonyacunar |
Ideally with PUT it is a full replacement operation. With PATCH you update parts |
| 20:47 |
|
tonyacunar |
There are good reads on that topic in Stackoverflow. |
| 20:51 |
|
Sna4x81 |
tonyacunar: I've been reading stackoverflow and other sites about it all morning. There are lots of resources online, but the vast majority tell one what not to do, or otherwise why someone is wrong, know what I mean? |
| 20:52 |
|
Sna4x81 |
The problem with PATCH is that in order to conform to the HTTP specs I then need to supply a changelist rather than just the resource. |
| 20:52 |
|
tonyacunar |
Correct - based on this little bit of information it sounds like you should provide the entire resource when you are using PUT |
| 20:52 |
|
Sna4x81 |
And supplying a description of changes is a hassle for my API consumers. |
| 20:54 |
|
Sna4x81 |
tonyacunar: But supplying the whole resource often requires a GET first, which 1) is more work on the consumer, especially for well-know resource URIs;2) more work on the server (validate and update a whole record when only one field is changing); 3) requires more bandwidth; 4) Introduces the possibility of inconsistencies when two people are updating the same resource, and both do a GET first. |
| 20:56 |
|
tonyacunar |
1) How are you updating something you dont have? You must have done a GET and stored the object somewhere before hand. 2) Don’t prematurely optimize. 3) How big is this object? Don’t prematurely optimize. 4) You can use a version number and reject if version has changed |
| 20:57 |
|
Sna4x81 |
Well I'm not prematurely optimizing in this case. Like I say, I have a suite of (non-conforming) APIs already that work great and are used pretty heavily. |
| 20:59 |
|
Sna4x81 |
For 1) Let's say I, as a developer, know the URI of some resource, maybe just by memory. It's valid with my APIs to simply PUT a single field to that URI right now, and that one field will get updated. I know that's invalid, but it sure is convenient. |
| 21:00 |
|
Sna4x81 |
There's another case: If a resource has 10 fields, and an API consumer is only interested in 3 of them, they can write client that only deals with those 3 fields. (E.g. maybe they're dealing with contacts and don't care about email addresses, they just want phone numbers). |
| 21:04 |
|
Sna4x81 |
Is it invalid to use POST to do partial updates? Like POST /people/1 {"firstName":"Bob"} To mean that seems wrong; it reads "create a person with ID of 1." |
| 21:04 |
|
tonyacunar |
Post should be used for resource creation |
| 21:05 |
|
Sna4x81 |
Yeah. |
| 21:06 |
|
Sna4x81 |
So on number 4, you mentioned using a version number and rejecting if the version changes. Doesn't that make the PUT non-idempotent? |
| 21:12 |
|
tonyacunar |
Yes you are correct |
| 22:14 |
|
|
k_j left #rest |
| 23:21 |
|
|
fuzzyhorns joined #rest |
