| Time |
S |
Nick |
Message |
| 00:58 |
|
|
tonyacunar joined #rest |
| 01:10 |
|
|
Phanes joined #rest |
| 01:10 |
|
|
Phanes joined #rest |
| 01:26 |
|
|
Phanes joined #rest |
| 01:26 |
|
|
Phanes joined #rest |
| 01:28 |
|
|
Phanes joined #rest |
| 01:28 |
|
|
Phanes joined #rest |
| 02:28 |
|
|
Phanes joined #rest |
| 02:28 |
|
|
Phanes joined #rest |
| 02:44 |
|
|
Phanes joined #rest |
| 02:44 |
|
|
Phanes joined #rest |
| 03:02 |
|
|
Phanes left #rest |
| 03:13 |
|
|
Coldblackice joined #rest |
| 05:42 |
|
|
ghostlight joined #rest |
| 05:42 |
|
|
ShekharReddy joined #rest |
| 07:05 |
|
|
_ollie joined #rest |
| 07:16 |
|
|
Tomatosoup- joined #rest |
| 07:51 |
|
|
_ollie joined #rest |
| 07:55 |
|
|
_ollie joined #rest |
| 10:30 |
|
|
vanHoesel joined #rest |
| 12:07 |
|
|
wsieroci joined #rest |
| 14:31 |
|
|
tonyacunar joined #rest |
| 15:16 |
|
|
tonyacunar joined #rest |
| 15:23 |
|
|
tbsf joined #rest |
| 16:32 |
|
|
tbsf joined #rest |
| 17:13 |
|
|
Tomatosoup- joined #rest |
| 17:41 |
|
|
ghostlight joined #rest |
| 17:41 |
|
|
ghostlight joined #rest |
| 17:42 |
|
|
ghostlight joined #rest |
| 17:42 |
|
|
ghostlight joined #rest |
| 17:43 |
|
|
ghostlight joined #rest |
| 17:43 |
|
|
ghostlight joined #rest |
| 17:44 |
|
|
ghostlight joined #rest |
| 17:44 |
|
|
ghostlight joined #rest |
| 17:45 |
|
|
ghostlight joined #rest |
| 17:45 |
|
|
ghostlight joined #rest |
| 17:46 |
|
|
ghostlight joined #rest |
| 17:46 |
|
|
ghostlight joined #rest |
| 17:47 |
|
|
ghostlight joined #rest |
| 17:48 |
|
|
ghostlight joined #rest |
| 17:55 |
|
|
tonyacunar joined #rest |
| 18:08 |
|
|
_ollie joined #rest |
| 18:24 |
|
|
Tomatosoup- joined #rest |
| 18:53 |
|
|
Coldblackice joined #rest |
| 19:21 |
|
|
tonyacunar joined #rest |
| 20:24 |
|
|
Coldblackice joined #rest |
| 20:27 |
|
|
Coldblackice joined #rest |
| 20:49 |
|
|
k_j joined #rest |
| 20:49 |
|
k_j |
hi |
| 20:50 |
|
k_j |
is /rest a good path prefix to indicate that under /rest itself there are resources obeying to a restful api? |
| 20:50 |
|
Tomatosoup- |
hey |
| 20:51 |
|
Tomatosoup- |
i use /api prefix (or api. subdomain) |
| 20:51 |
|
k_j |
Tomatosoup-, ok, but isn't it too generic? |
| 20:51 |
|
k_j |
i mean, what api? |
| 20:53 |
|
asdf |
i'm not sure it's actually useful but sure, you can use /rest |
| 20:53 |
|
asdf |
well, basically the only information the client needs to know before it talks to your api, is the root url :) |
| 20:53 |
|
Tomatosoup- |
k_j: it is generic, but rest is just an architectural style |
| 20:54 |
|
k_j |
asdf, the reason why i need a prefix is that my server is ,unfortunately,full of non-restful resources, while moving everything to rest , i want a way to distinguish between these two categories |
| 20:54 |
|
Tomatosoup- |
like asdf said it doesnt really matter what the prefix will be |
| 20:55 |
|
asdf |
people often put a version in the url, so you could also start with that: /v2 |
| 20:55 |
|
asdf |
that would mean that later when you do a next system upgrade, you'll be transitioning from /v2 to /v3, as opposed to from /rest to something else |
| 20:55 |
|
k_j |
it makes sense |
| 20:55 |
|
Tomatosoup- |
actually, it is more restful to pass version via vendor, not via url |
| 20:57 |
|
Tomatosoup- |
with mime type http header, like this: application/vnd.restapi[.version]+json |
| 21:14 |
|
|
foist joined #rest |
| 21:31 |
|
|
tonyacunar joined #rest |
| 21:49 |
|
k_j |
what should the server answer if the answer sets application/xml , for example, while the server is only serving json? should the server give a bad request in the naser with the application header set to json? |
| 21:49 |
|
k_j |
I miswrote |
| 21:50 |
|
k_j |
what should the server answer if the clients asks application/xml , for example, while the server is only serving json? should the server give a bad request in the naser with the application header set to json? |
| 21:54 |
|
asdf |
yep bad request is fine, with any content really; there was a status code specifically for that but 400 is better than nothing :) |
| 21:54 |
|
asdf |
oh, 415 was the more specific one |
| 21:55 |
|
asdf |
content doesn't matter all that much, since the client asked for xml, so in all probability it won't be able to parse your json anyway |
| 21:55 |
|
asdf |
well unless you want to bother to sending the error in xml, but i doubt you do :p |
| 21:56 |
|
k_j |
thanks,makes sense |
| 21:56 |
|
asdf |
it's good if the error message content is human readable though, so the dev that asked for xml can correct their ways ;) |
| 21:56 |
|
asdf |
(unlike some other APIs that just send a 400 with empty content for any ol' error) |
| 21:56 |
|
asdf |
(looking at you, google cal) |
| 21:59 |
|
k_j |
asdf, and what if the clients does not set anny application header at all? is it a valid request meaning that the server can just continue with serving the request as it prefers? |
| 22:02 |
|
asdf |
k_j, you mean no Accept header? well it is valid http |
| 22:03 |
|
k_j |
asdf, ok thanks |
| 22:03 |
|
asdf |
technically you could send back anything at all but yeah, sending an .exe won't be helpful, right :) |
| 22:04 |
|
asdf |
i don't mean it's a good practice to not send Accept; clients should send it - as you can see not using Accept makes it hard for everyone |
| 22:28 |
|
k_j |
asdf, do you think it's a good idea to _always_ set some "important" headers in any answer (errors or not) like "Allow", to give informations about the supported methods |
| 22:29 |
|
k_j |
asdf, i mean, the more non-contextual infos you give to the client, the better it is for it to understand the situation |
| 22:30 |
|
asdf |
hmm, non-contextual? |
| 22:30 |
|
Tomatosoup- |
k_j: generally, you provide information about supported methods in OPTIONS |
| 22:30 |
|
k_j |
i mean, "Allow: POST" makes obviously sense in an answer if the client is trying GET on a resource which only supports POST. Ok. My question is if in ANY answer it is ok to set "Allow: POST" |
| 22:31 |
|
asdf |
k_j, btw, are you using any specific mediatype? (like HAL, or collection+json, or json-ld, or..) |
| 22:31 |
|
k_j |
Tomatosoup-, but 405 requites this : "The response MUST include an Allow header containing a list of valid methods for the requested resource." |
| 22:32 |
|
k_j |
asdf, plain json |
| 22:32 |
|
asdf |
(or jsonapi.org is a popular one too) |
| 22:32 |
|
Tomatosoup- |
k_j: you should always have Allow filled with available methods |
| 22:35 |
|
asdf |
the reason i'm asking is, yeah, you can put all kinds of stuff in headers - people sometimes use the Link header for that; but REST is about hypermedia, so instead of sending all kinds of data in the headers, you can try to put them (like eg. the links) inside the response body (and the mediatypes i mentioned each have a way of doing that) |
| 22:36 |
|
asdf |
as for Allow, sure, do send it, i guess it helps. But still be prepared for clients to send the not allowed verbs as well :) |
| 22:37 |
|
|
tonyacunar joined #rest |
| 22:38 |
|
Tomatosoup- |
asdf: well, in case of method being not allowed you just return 405, hypermedia wont help here |
| 22:38 |
|
asdf |
for example collection+json will even give the client templates for the queries it can send |
| 22:39 |
|
asdf |
so sending a {"template": {...}} will tell the client that not only it can PUT to update this resource, but also what data is acceptable |
| 22:39 |
|
asdf |
so that's more powerful than just Allow |
| 22:39 |
|
asdf |
(html is similar!) |
| 22:41 |
|
k_j |
is jsonapi.org very common? |
| 22:43 |
|
k_j |
if i base my json stuff on a well-known api, it might be possible to find out a plugin for firefox rendering the resources automatically from server |
| 22:43 |
|
k_j |
is it correct? |
| 22:45 |
|
asdf |
technically yeah but those aren't super popular :( jsonapi has some big names behind it, but yeah |
| 22:46 |
|
asdf |
i mean when most people think 'REST API', they think 'just any ol api that happens to return json and uses a few http status codes' |
| 22:46 |
|
asdf |
the hypermedia part is often omitted |
| 22:46 |
|
asdf |
and yes, tool support is a major reason why those are useful |
| 22:46 |
|
k_j |
by hypermedia part you mean HATEOS right? |
| 22:46 |
|
asdf |
sure |
| 22:47 |
|
Tomatosoup- |
asdf: i would even say that it is almost always omitted |
| 22:48 |
|
asdf |
(or, tool support is a major reason why they _might_ be useful, as personally i dont use any browser extensions to help that) |
