Timeline for Is this service considered "an API"? Could it benefit from being Restful?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Sep 18, 2023 at 13:37 | history | edited | JimmyJames | CC BY-SA 4.0 |
fixed grammar (and more because just fixing grammar resulted in a too-small edit)
|
| S Sep 18, 2023 at 13:37 | history | suggested | ShinTakezou | CC BY-SA 4.0 |
fixed grammar (and more because just fixing grammar resulted in a too-small edit)
|
| Sep 16, 2023 at 17:09 | review | Suggested edits | |||
| S Sep 18, 2023 at 13:37 | |||||
| May 31, 2023 at 20:20 | comment | added | Filip Milovanović | @JacquesB HTTP level caching is not necessarily happening client-side, but may occur in the intermediaries in the network infrastructure, making responses faster and taking the load off of the server. | |
| May 31, 2023 at 13:23 | comment | added | JimmyJames | @JacquesB "which means the code already have the data!" Not necessarily. Data, especially from APIs can change. And you do things like put in a If-Modified-Since header to only pull data when it is actually changed on the server. I've never understood why you wouldn't follow HTTP standards when you can. Did the SOAP-WSDL debacle teach us nothing? | |
| May 31, 2023 at 10:48 | comment | added | Flater | @JacquesB: I can make the same argument about browsers being able to store the result they get from a URL and not fetch it a second time. The reason for wanting to cache something is irrespective of the specific data format that is being cached. | |
| May 31, 2023 at 6:39 | comment | added | JacquesB | @Flater: I'm arguing against client-side HTTP level caching in a JavsScript client because it is next to useless. It can only cache data which is fetched by the client side code, which means the code already have the data! For this reason, client-side frameworks have their own state management libraries. | |
| May 31, 2023 at 6:22 | comment | added | Flater | @JacquesB: What you're mentioning is a form of caching. It is not the only way to cache things. One could also use an existing HTTP caching client pretty much out of the box for the purpose of wrapping it around a REST resource. That is not a must, but it is one way (out of many possible ways) of doing it. I'm not sure why you're arguing for its exclusion as a valid approach. | |
| May 31, 2023 at 6:18 | comment | added | JacquesB | @Flater: Yes caching is great, but in a JavaScript client you would just cache data in a variable or whatever. If you don't need to update the data, just don't make a request for it. No need for using the HTTP level caching which is less fine-grained and much more complex to configure. | |
| May 31, 2023 at 6:16 | comment | added | Flater | @JacquesB The argumentation for any client-side cache remains the same regardless of what specific data (or data format) is being cached. The argumentations for client-side caches and serverside caches are different, but individually they are consistent for any kind of data that you are working with, regardless of it being JSON data, images, web pages, ... | |
| May 31, 2023 at 6:12 | comment | added | Flater | @JacquesB: The argumentation for any client-side cache remains the same regardless of what specific data (or data format) is being cached. | |
| May 31, 2023 at 5:40 | comment | added | JacquesB | HTTP caching is designed for caching web pages and images and such. I don't see how it is useful in the context of an API client? E.g. if you fetch a JSON data object in a javascript client, you just keep the object around as long as you need it. You wouldn't make requests for data you already have and (isn't stale), so request layer caching is not necessary. | |
| May 30, 2023 at 19:27 | history | answered | JimmyJames | CC BY-SA 4.0 |