Timeline for REST API Design: Multiple resources and authorization
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 22, 2019 at 14:41 | vote | accept | Slav | ||
| Jun 26, 2018 at 20:29 | history | edited | Dherik | CC BY-SA 4.0 | deleted 10 characters in body |
| Mar 28, 2018 at 12:17 | history | edited | Dherik | CC BY-SA 3.0 | added 168 characters in body |
| Mar 28, 2018 at 11:58 | history | edited | Dherik | CC BY-SA 3.0 | added 635 characters in body |
| Mar 28, 2018 at 11:08 | comment | added | Laiv | Versioning in REST could be really counterproductive. Overall when the API doesn't implement Hateoas and the consumers are out of your hand to keep update. For instance, mobile apps. May the forest does not prevent you from seeing the trees, URIs could be something like /8asdd8ad-3343-ada9dd-asdads99asdand still make things works. Extract all the meaning possible from the identifier and place it where it should be. in the contract. Whether the contract is reliable or not is a matter of design. | |
| Mar 28, 2018 at 10:32 | comment | added | Dherik | @Laiv, Ignore some informations is alright in simplest cases, but can be a problem to document how your API works (imagine a Swagger on that) and even understand, because we will create different kinds of information groups that wont play together (like channel and title for a twitter post). Also the versioning only affect one platform and is easier to maintain the code (divide to conquer). I will add this informations on the post. | |
| Mar 28, 2018 at 6:40 | comment | added | Laiv | On the other hand, seems to me that you are putting too much emphasis on communicating intention through the URI. URI are meant to be meaningless. The simpler are the URI's path, the better. As I commented, simple URIs are less prone to change and as we know, in REST, these identifiers are as good as their faculty to remain unchanged over the time. | |
| Mar 28, 2018 at 6:32 | comment | added | Laiv | Maybe you would like to add a new platform that needs a new information to be passed together with the user reference. Transpiring the services' details that you are trying to hide just make the facade useless. Body request inputs can be nullified and ignored on the server side. It's a matter of mappings. In other words, how you turn one "post" into a 3rd party post is an implementation detail. You said use a single endpoint is a risk. Not really. It's the safest and more scalable approach in the long run since clients don't to be aware of the "needs" of each platform. | |
| Mar 27, 2018 at 23:12 | history | edited | Dherik | CC BY-SA 3.0 | added 2 characters in body |
| Mar 27, 2018 at 23:06 | history | edited | Dherik | CC BY-SA 3.0 | added 165 characters in body |
| Mar 27, 2018 at 22:59 | history | answered | Dherik | CC BY-SA 3.0 |