Search Results

Search found 4 results on 1 pages for 'bckpwrld'.

Page 1/1 | 1 

  • Quite confused about what constitutes Current state of a resource

    - by bckpwrld
    From REST in Practice: Hypermedia and Systems Architecture: The current state of a resource is a combination of: The values of information items belonging to that resource Links to related resources Links that represent a transition to a possible future state of the current resource The results of evaluating any business rules that relate the resource to other local resources a) why would "links to related resources" also represent the current state of a resource? b) I also don't quite understand why "Links that represent a transition to a possible future state of the current resource" also represent the the current state. Namely, those links represent the possibility, not the current state. Analogy would be an int variable set to value 10. It's possible that in the future this variable will get processed and set to value 100, but we don't claim its current state also includes possible future state of 100?! thank you

    Read the article

  • POST and PUT requests – is it just the convention?

    - by bckpwrld
    I've read quite a few articles on the difference between POST and PUT and in when the two should be used. But there are still few things confusing me ( hopefully questions will make some sense ): 1) We should use PUT to create resources when we want clients to specify the URI of the newly created resources and we should use POST to create resources when we let service generate the URI of the newly created resources. a) Is it just by convention that POST create request doesn't contain an URI of the newly created resource or POST create request actually can't contain the URI of the newly created resource? b) PUT has idempotent semantics and thus can be safely used for absolute updates ( ie we send entire state of the resource to the server ), but not also for relative updates ( ie we send just changes to the resource state ), since that would violate its semantics. But I assume it's still possible for PUT to send relative updates to the server, it's just that in that case the PUT update won't be idempotent? 2) I've read somewhere that we should "use POST to append a resource to a collection identified by a service-generated URI". a) What exactly does that mean? That if URIs for the resources were generated by a server ( thus the resources were created via POST ), then ALL subsequent resources should also be created via POST? Thus, in such situation no resource should be created via PUT? b) If my assumption under a) is correct, could you elaborate why we shouldn't create some resources via POST and some via PUT ( assuming server already contains a collection of resources created via POST )? REPLY: 1) Please correct me if I'm wrong, but from your post and from the link you've posted, it seems: a) The Request-URI in POST is interpreted by server as the URI of the service. Thus, it could just as easily be interpreted as an URI of a newly created resource, if server code was written to recognize Request-URI as such b) Similarly, PUT is able to send relative updates, it's just that service code is usually written such that it will complain if PUT updates are relative. 2) Usually, create has fallen into the POST camp, because of the idea of "appending to a collection." It's become the way to append a resource to a list of resources. I don't quite understand the reasoning behind the idea of "appending to a collection" and why this idea prefers POST for create. Namely, if we create 10 resources via PUT, then server will contain a collection of 10 resources and if we then create another resource, then server will append this resource to that collection ( which will now contain 11 resources )?! Uh, this is kinda confusing thank you

    Read the article

  • URIs and Resource vs Resource representation

    - by bckpwrld
    URL is an URI which identifies a resource by location. Resource representation is a view of resource's state. This view is encoded in one or more transferable formats, such as XHTML, Atom, XML, MP3 ... URIs associate resource representations with their resources a) So I assume URI identifies a resource and not resource representation? b) I've read that relationship between an URI and resource representation is one to many. Assuming we're talking about URL, how can a single URL address more than one resource representation? thank you

    Read the article

  • What exactly are Link Relation Values?

    - by bckpwrld
    From REST in Practice: Hypermedia and Systems Architecture: For computer-to-computer interactions, we advertise protocol information by embedding links in representations, much as we do with the human Web. To describe a link's purpose, we annotate it. Annotations indicate what the linked resource means to the current resource: “status of your coffee order” “payment” and so on. We call such annotated links hypermedia controls, reflecting their enhanced capabilities over raw URIs. ... link relation values, which describe the roles of linked resources ... Link relation values help consumers understand why they might want to activate a hypermedia control. They do so by indicating the role of the linked resource in the context of the current representation. I interpret the above quotes as saying that Hypermedia control contains both a link to a resource and an annotation describing the role of linked resource in the context of the current representation. And we call this annotation ( which describes the role of linked resource ) a link relation value. Is my assumption correct or does the term link relation value actually describe something different? Thank you

    Read the article

1