| Time |
S |
Nick |
Message |
| 00:02 |
|
|
tbsf joined #rest |
| 01:32 |
|
|
fuzzyhorns joined #rest |
| 02:22 |
|
|
tbsf joined #rest |
| 06:23 |
|
|
tbsf joined #rest |
| 08:59 |
|
|
interop_madness joined #rest |
| 10:23 |
|
|
tbsf joined #rest |
| 13:17 |
|
|
tbsf joined #rest |
| 13:53 |
|
|
mac- joined #rest |
| 13:53 |
|
mac- |
hey guys |
| 13:53 |
|
mac- |
I'm learning now REST, the fundamentals |
| 13:54 |
|
mac- |
and I've read that in REST the server owns all of its URLs with exception of single entry point |
| 13:55 |
|
mac- |
I don't understand it |
| 13:55 |
|
mac- |
could you clarify it a little for me ? |
| 13:58 |
|
asdf |
mac-, this means that the client must not construct URLs themselves; it shouldn't eg know that a url /items exists on the server; instead, it should go to the server's entry point /, and in the returned document, there should be a link to /items |
| 13:58 |
|
asdf |
this is what happens with human-readable web - you go to amazon.com, and you discover there a link to a product |
| 13:59 |
|
mac- |
uhm |
| 13:59 |
|
mac- |
but it occurs every time client wish to do sth on the server or once when client connects for the first time ? |
| 14:00 |
|
asdf |
caching the urls is fine |
| 14:00 |
|
asdf |
in human-readable web, there's bookmarks, right :) |
| 14:01 |
|
mac- |
yeah but tghey wrote also, that server can change its URLs and client won't notice any pain because of it |
| 14:02 |
|
mac- |
then when client has cached URLs somwhere there must be some command to refresh send by the server to clients |
| 14:03 |
|
mac- |
in other scenario client will end up with 404 or silly responses |
| 14:03 |
|
asdf |
well, there's 3xx responses |
| 14:03 |
|
asdf |
but yes, in general, cache invalidation is one of the famous Hard Things In Computing, isn't it ;) |
| 14:04 |
|
mac- |
yep |
| 14:04 |
|
mac- |
ok, thx |
| 14:05 |
|
mac- |
they didn't write anything about document with links from response of entry point |
| 14:22 |
|
asdf |
mac-, the big idea is HATEOAS - all the stuff needs to be discoverable via links; for example, collection+json, or json-ld, are mediatypes that tell you how to organize links |
| 14:41 |
|
mac- |
uhm |
| 14:41 |
|
mac- |
one more question |
| 14:41 |
|
mac- |
https://martinfowler.com/articles/images/richardsonMaturityModel/overview.png |
| 14:41 |
|
mac- |
I guess you know it :) |
| 14:42 |
|
mac- |
I read that level 0 through 3 represent incremental steps towards REST but do not represent different levels of REST |
| 14:43 |
|
mac- |
how should I understand this senstence ? |
| 14:43 |
|
asdf |
that just having resources doesn't mean you implemented "REST level 1", it means you made one step towards making your program RESTful |
| 14:44 |
|
asdf |
and to call it "REST", you need to do everything on that list |
| 14:44 |
|
asdf |
of course, people call all kinds of things "REST" |
| 14:44 |
|
asdf |
some people have taken to calling the classic-fielding-REST-thing, a "hypermedia API", to avoid confusion with the common "just any api that returns json" |
| 14:45 |
|
asdf |
the "hyper" in "hypermedia" means links ;) |
| 14:47 |
|
mac- |
uhm |
| 14:48 |
|
mac- |
ok but they wrote also: only level 3 in this model can actually be considered REST |
| 14:49 |
|
mac- |
and as I understand so far because hypermedia represented now as hypertext can transport state inside during communication ? |
| 14:56 |
|
asdf |
well, many things can transport state; in REST, as understood by Fowler here, hypermedia is used for that |
| 14:56 |
|
asdf |
ie. some notation that contains links to the related resources (and not eg. just ids of the related resources) |
| 14:58 |
|
mac- |
yeah, inside hypertext you can put links to other entities rather than just their IDs |
| 15:01 |
|
mac- |
hm, then sentence 'only level 3 in this model can actually be considered REST' means that only lvl3 is capable of contain links to the related resources |
| 15:24 |
|
asdf |
don't overthink that model :) |
| 15:34 |
|
|
tbsf joined #rest |
| 15:36 |
|
|
tbsf joined #rest |
| 15:36 |
|
|
tbsf joined #rest |
| 16:08 |
|
mac- |
asdf: actually I'm trying to just understand it correctly |
| 17:21 |
|
|
wsieroci joined #rest |
| 17:27 |
|
|
wsieroci joined #rest |
| 19:02 |
|
|
d4rklit3 joined #rest |
| 19:02 |
|
|
wsieroci joined #rest |
| 20:25 |
|
|
wsieroci joined #rest |
| 20:30 |
|
|
tbsf joined #rest |
| 20:31 |
|
|
tbsf joined #rest |
| 22:36 |
|
pdurbin |
mac-: an example of a single entry point is the Service Document in the AtomPub spec: https://tools.ietf.org/html/rfc5023 |
| 22:43 |
|
mac- |
thx |
| 22:43 |
|
mac- |
will check it |
| 22:43 |
|
|
fuzzyhorns joined #rest |
| 23:25 |
|
|
wsiqueir joined #rest |
| 23:44 |
|
|
Haudegen joined #rest |
