Home > Blockchain >  Is it allowed to access same resource from multiple endpoints in REST API?
Is it allowed to access same resource from multiple endpoints in REST API?

Time:05-03

I have two endpoints

{ path: "/pages", description: "Retrieves information about all public pages. If user is logged in, the call would return all pages that belong to the user and that are public.", arguments: "page, owner_id, creation_date, page_id, status, author", },

{ path: "/pages/pageId", description: "Retrieves information about specific page.", arguments: "page, owner_id, creation_date, status, author", }

I could retrieve a page using /pages?pageId=xxxxx and /pages/pageId. Would this broke DX (developer experience) or any other REST convention (like consistency)?

CodePudding user response:

I could retrieve a page using /pages?pageId=xxxxx and /pages/pageId. Would this broke DX (developer experience) or any other REST convention (like consistency)?

Nothing wrong with that from a REST perspective - it is normal that we might have multiple resources (each with their own identifier) that have the same representations.

For example, the "authors' preferred version" of an academic paper is a mapping whose value changes over time, whereas a mapping to "the paper published in the proceedings of conference X" is static. These are two distinct resources, even if they both map to the same value at some point in time. The distinction is necessary so that both resources can be identified and referenced independently. A similar example from software engineering is the separate identification of a version-controlled source code file when referring to the "latest revision", "revision number 1.2.7", or "revision included with the Orange release." -- Fielding, 2000

Note that general purpose components won't know that two different resource identifiers point to "the same" representations. For instance, if we have cached copies of both resources, and we update one of them (ie POST, PUT, PATCH), the general purpose component won't know that the other has also changed.


You can, of course, design your resources so that one spelling redirects to the other:

GET /pages?pageId=12345
307 Temporary Redirect
Location: /pages/12345

You can also use HTTP metadata is the representation of one resource is "really" from a different resource

GET /pages?pageId=12345
200 OK
Content-Location: /pages/12345
...

CodePudding user response:

A resource can have multiple identifiers (IRIs) and multiple representations. The representations can depend on authorization or anything else that comes with the request (e.g. different request headers) until it respects the statelessness constraint. REST works with standards or at least recommendations according to the uniform interface constraint, so I would not care much about IRI conventions, but you can follow the nice IRI convention if you want to. Normally you got back hypertext in the case of regex, so instead of caring about the IRI structure your client follow hyperlinks and they use the metadata of the hyperlink to decide what it is doing, not the IRI structure, which is completely irrelevant if we talk about REST as it was described by Fielding.

  • Related