Timeline for answer to Designing a REST api by URI vs query string by K. Alan Bates
Current License: CC BY-SA 4.0
Post Revisions
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2021 at 7:34 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
|
|
| May 2, 2019 at 19:40 | comment | added | K. Alan Bates | @Maggyero I see why you have concerns with the guidance provided to you so far. I should be able to help you find your way to where you are trying to go. I'll put a response together for you tonight | |
| May 2, 2019 at 18:01 | comment | added | K. Alan Bates | @Maggyero I can take a look at your question and see if there is any additional perspective that I can add. I can't answer your question directly through this comment because I don't know what tools you have available to your service client. | |
| May 2, 2019 at 16:40 | comment | added | Géry Ogam |
… Basically I am told to give up the hierarchical structure in my URIs for a flat structure. It seems to go against the role of the path component as defined in RFC 3986. The only advantage of this that I see is for querying: with a single level path component (/artists/{artist_uuid}, /albums/{album_uuid} and /songs/{song_uuid}), one can easily build queries such as /songs/?artist={artist_uuid}. I cannot think of a way to achieve that in one request with a multi-level path component (/artists/{artist_name}/albums/{album_name}/songs/{song_name}). Any suggestion?
|
|
| May 2, 2019 at 16:25 | comment | added | Géry Ogam |
It's good to see someone following RFC 3986 for URIs, and just that. Lots of answers on Stackoverflow state that the query component should be used as a filter (for no reason), or that the path component should not have a hierarchy beyond 1 level (e.g., /artists/{artist}) or 2 levels (e.g., /artists/{artist}/albums/), arbitrarily prohibiting lower levels (e.g., /artists/{artist}/albums/{album}/songs/{song}). So I need your expertise on my recent post (I haven't accepted the given answer yet as something feels wrong): softwareengineering.stackexchange.com/q/391242/184279
|
|
| Dec 14, 2018 at 12:25 | history | edited | K. Alan Bates | CC BY-SA 4.0 |
added 36 characters in body; added 2 characters in body
|
| Oct 24, 2018 at 15:36 | comment | added | K. Alan Bates | @adjenks regarding your use case for providing an empty array instead of a 404: that is building a curated protocol.You are encoding meaning behind the type of response returned when resources are not found and the structure involved is very particular to your system and to its goals.Ultimately, your gain is that you avoid having to make a secondary call to check existence of your secondary entity (author).You can constrain that use case entirely within the client, so your simplification actually complicates matters rather than clarifying them.Make the second call if you care why you got a 404 | |
| Oct 24, 2018 at 14:07 | comment | added | K. Alan Bates | (continued) REST requires that if you are using "URL"s and HTTP/1.1, you must adhere to RFC 3986 for the requirements of URIs and RFCs 7230,7231,7232,7233,7234, and 7235 for the requirements of HTTP/1.1. If you wish to declare your system "RESTful" and declare support for URLs and HTTP/1.1, your amendment would be forbidden. REST is intentionally an exceptionally strict architectural style. (end) | |
| Oct 24, 2018 at 13:56 | comment | added | K. Alan Bates | @adjenks (continued) ...you are perfectly within reason to define your own client-server interaction model which has deviations from specified, expected behavior.But when you do that, you are unequivocally building a system which is NOT RESTful and the context of this question and answer centers around building a RESTful system.Your amendment to switch system interactions with urls and http from being 'resource location based' to being 'search result set' based is inconsistent with the RESTful architectural style.(continued=>) | |
| Oct 24, 2018 at 13:33 | comment | added | K. Alan Bates | @adjenks You didn't learn that from formal specifications. Structurally, the constituents of a url can be thought of as containing a "root" if that helps you reason about the purposes for the constituent parts, but ultimately the query string is not a display filter against a resource identified via the path. The query string is a first class citizen of a url. When you find no resources on the server which match your url (including the query string) 404 is the means defined within http to communicate this. The interaction model you pose introduces a distinction without a difference. | |
| Oct 24, 2018 at 9:29 | comment | added | ADJenks | I always believed 404 to indicate that the root URL of the resource was not found, i.e. the collection as a whole. So If you queried /books?author=Jim and there were no books by jim, yo'd receive an empty set []. But if you queried /articles?author=Jim but the articles resource didn't even exist as a collection 404 would help to indicate that there's no use in looking for any articles at all. | |
| Oct 19, 2018 at 13:08 | history | edited | K. Alan Bates | CC BY-SA 4.0 |
Changed "transport protocol" to "application protocol." I meant to say transfer in the first usage, and just now caught that I said "transport."
|
| Mar 20, 2017 at 17:48 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 1 character in body
|
| Jan 30, 2017 at 17:24 | comment | added | K. Alan Bates | @RobertoAloi It seems counterintuitive to me to communicate your own "No Items Found" interface through an empty set when HTTP already has a definition for that. The basic principle is that you are asking the server to return "thing(s)" and if there are no "thing(s)" to return, the server communicates that with "404 - Not Found" What's counterintuitive about that? | |
| Jan 27, 2017 at 22:57 | comment | added | Roberto Aloi | @K.AlanBates Would the fact that the query string doesn't contain "filters" but attributes that identify the resource imply a 404 returned if the result of the search is the empty set? That would sound counterintuitive for me. | |
| Aug 22, 2016 at 16:08 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 906 characters in body
|
| Feb 18, 2016 at 14:31 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
deleted 4 characters in body
|
| Feb 18, 2016 at 14:31 | comment | added | K. Alan Bates | @Myster Yes and no. A "tree" is technically known as an arborescent graph(directed and acyclic), but this is a hierarchical structure. I did make a mistake in my final point where I used the "undirected" fragment; I meant to say "directed" and I hadn't noticed that I had reversed it. I probably wouldn't have caught it if you had not made your comment. | |
| Feb 18, 2016 at 1:49 | comment | added | Myster | Isn't a family tree really a graph not a tree, and not at all hierarchical. considering multiple parents, divorce and re-marriage etc. | |
| Jan 14, 2016 at 7:10 | vote | accept | HiChews123 | ||
| Nov 23, 2015 at 18:21 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 4 characters in body
|
| Nov 23, 2015 at 12:25 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 45 characters in body
|
| Jun 30, 2015 at 14:25 | comment | added | K. Alan Bates | @user2313838 (comment probably not best medium for elaboration) No. The global restriction you seem to have placed upon RFC3986 for specifying only the resolution of relative URI references is not present. The mentioning in the RFC of "relative URIs" is permissive, not exclusive of other approaches. The hierarchical nature of the path described in the general syntax imports no context of defining references relative to a separately defined context. The hierarchical nature of the path is to identify hierarchically organized data. If your data is hierarchical, thou shalt use the path. | |
| Jun 30, 2015 at 13:58 | comment | added | user2313838 | The RFC is only concerned with hierarchy insofar as it defines a syntax and algorithm for resolving relative URI references. Could you elaborate or cite some sources explaining why the examples in the original post are not conforming? | |
| Jun 30, 2015 at 12:45 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 103 characters in body
|
| Jun 4, 2015 at 3:16 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 12 characters in body
|
| Jun 4, 2015 at 3:02 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 217 characters in body
|
| Jun 4, 2015 at 2:48 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 3250 characters in body
|
| Jun 3, 2015 at 21:56 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 44 characters in body
|
| Jun 3, 2015 at 18:45 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
added 59 characters in body
|
| Jun 3, 2015 at 15:15 | history | edited | K. Alan Bates | CC BY-SA 3.0 |
Included excerpt from RFC3986#section-3.4
|
| Jun 3, 2015 at 15:10 | review | First posts | |||
| Jun 3, 2015 at 20:49 | |||||
| Jun 3, 2015 at 15:06 | history | answered | K. Alan Bates | CC BY-SA 3.0 |