â–˛ 780 â–Ľ REST my ass đź’© (eviltoast.org) submitted 1 year ago by orhtej2@eviltoast.org to c/programmer_humor@programming.dev 102 comments fedilink hide all child comments
[–] Aatube@kbin.melroy.org 6 points 1 year ago (11 children) how would you return metadata or more detailed error codes? permalink fedilink source parent hideshow 11 child comments replies: [–] eager_eagle@lemmy.world 5 points 1 year ago returning a 400 never prevented me from adding more info to the response permalink fedilink source parent [–] Slotos@feddit.nl 5 points 1 year ago (1 child) However you like, REST doesn’t dictate anything there. Just be consistent and use hypermedia. JSON APIs almost never follow REST because they almost never use JSON as hypertext. Worse, no complete stable hypertext JSON standard exists. There’s JSON-HAL, but it lacks a way to represent resource templates (think HTML’s <form>). Therefore, with JSON APIs ignoring one of the most basic idea behind REST, why would anyone expect them to follow another idea of REST - consistency? REST is a deceptively simple concept. Any time you build an HTML website a human can navigate without consulting documentation, you’re doing it better than vast majority of swagger documented corporate APIs. permalink fedilink source parent hideshow 1 child comment replies: [–] jj4211@lemmy.world 2 points 1 year ago Fun fact, I actually did implement JSON-HAL and peers wondered why I was putting this "silly _links dictionary member" in there. I'll say I've seen other REST APIs using json and at least honor the concept of hypermedia, but in a useless way. They'll have links specified, but even within their API no consistency on what dictionary keys would refer to related resources versus data. permalink fedilink source parent [–] tempest@lemmy.ca 3 points 1 year ago (7 children) The argument probably goes something like " if you adhere strictly to REST the error codes are all you need" and then metadata can be sent in response headers. permalink fedilink source parent hideshow 7 child comments replies: [–] Aatube@kbin.melroy.org 3 points 1 year ago* (6 children) how should a REST API respond to the client sending a URL the ends in a string instead of a numeric ID? like api.social/users/ceeforayteen instead of api.socail/users/11037 permalink fedilink source parent hideshow 6 child comments replies: [–] locuester@lemmy.zip 8 points 1 year ago (3 children) I would do a 400 (Bad Request). Then, with varying amounts of detail depending on the scale of the project and the framework capability, the response body would be something like: { “error”:true, “reason”: “validation”, “detail”: “user id should be numeric” } permalink fedilink source parent hideshow 3 child comments replies: [–] Aatube@kbin.melroy.org 2 points 1 year ago (2 children) that's what i would do too—a JSON response. or is that not what "JSON API" means? permalink fedilink source parent hideshow 2 child comments replies: [–] locuester@lemmy.zip 3 points 1 year ago* (last edited 1 year ago) (1 child) A RESTful service is (usually as of today) a JSON API. They aren’t mutually exclusive things. There’s no black and white definition there. However, when someone is creating a RESTful service, they’re stating that they’ll be paying mind to HTTP Verbs and status codes as a fundamental part of their design. In the original image posted, that dev clearly wasn’t paying mind to the HTTP layer and as such a commenter called it just a “JSON API”, which is the catchall, ugly, Wild West, typical way of doing things (always return 200, errors are in the json). Once again tho, it’s not black and white. Others can and will disagree and want to be pedantic. I’ve been a professional dev for 35 years, devs love to argue abt this shit. permalink fedilink source parent hideshow 1 child comment replies: [–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent [–] tempest@lemmy.ca 3 points 1 year ago Depends on the verb and the application. If the string is valid 200, if it isn't 400, 404. permalink fedilink source parent [–] thesmokingman@programming.dev 3 points 1 year ago It’s still just another type of ID so you can do lookups on it. Nothing would change. UUIDs are used all the time. permalink fedilink source parent
[–] eager_eagle@lemmy.world 5 points 1 year ago returning a 400 never prevented me from adding more info to the response permalink fedilink source parent
[–] Slotos@feddit.nl 5 points 1 year ago (1 child) However you like, REST doesn’t dictate anything there. Just be consistent and use hypermedia. JSON APIs almost never follow REST because they almost never use JSON as hypertext. Worse, no complete stable hypertext JSON standard exists. There’s JSON-HAL, but it lacks a way to represent resource templates (think HTML’s <form>). Therefore, with JSON APIs ignoring one of the most basic idea behind REST, why would anyone expect them to follow another idea of REST - consistency? REST is a deceptively simple concept. Any time you build an HTML website a human can navigate without consulting documentation, you’re doing it better than vast majority of swagger documented corporate APIs. permalink fedilink source parent hideshow 1 child comment replies: [–] jj4211@lemmy.world 2 points 1 year ago Fun fact, I actually did implement JSON-HAL and peers wondered why I was putting this "silly _links dictionary member" in there. I'll say I've seen other REST APIs using json and at least honor the concept of hypermedia, but in a useless way. They'll have links specified, but even within their API no consistency on what dictionary keys would refer to related resources versus data. permalink fedilink source parent
[–] jj4211@lemmy.world 2 points 1 year ago Fun fact, I actually did implement JSON-HAL and peers wondered why I was putting this "silly _links dictionary member" in there. I'll say I've seen other REST APIs using json and at least honor the concept of hypermedia, but in a useless way. They'll have links specified, but even within their API no consistency on what dictionary keys would refer to related resources versus data. permalink fedilink source parent
[–] tempest@lemmy.ca 3 points 1 year ago (7 children) The argument probably goes something like " if you adhere strictly to REST the error codes are all you need" and then metadata can be sent in response headers. permalink fedilink source parent hideshow 7 child comments replies: [–] Aatube@kbin.melroy.org 3 points 1 year ago* (6 children) how should a REST API respond to the client sending a URL the ends in a string instead of a numeric ID? like api.social/users/ceeforayteen instead of api.socail/users/11037 permalink fedilink source parent hideshow 6 child comments replies: [–] locuester@lemmy.zip 8 points 1 year ago (3 children) I would do a 400 (Bad Request). Then, with varying amounts of detail depending on the scale of the project and the framework capability, the response body would be something like: { “error”:true, “reason”: “validation”, “detail”: “user id should be numeric” } permalink fedilink source parent hideshow 3 child comments replies: [–] Aatube@kbin.melroy.org 2 points 1 year ago (2 children) that's what i would do too—a JSON response. or is that not what "JSON API" means? permalink fedilink source parent hideshow 2 child comments replies: [–] locuester@lemmy.zip 3 points 1 year ago* (last edited 1 year ago) (1 child) A RESTful service is (usually as of today) a JSON API. They aren’t mutually exclusive things. There’s no black and white definition there. However, when someone is creating a RESTful service, they’re stating that they’ll be paying mind to HTTP Verbs and status codes as a fundamental part of their design. In the original image posted, that dev clearly wasn’t paying mind to the HTTP layer and as such a commenter called it just a “JSON API”, which is the catchall, ugly, Wild West, typical way of doing things (always return 200, errors are in the json). Once again tho, it’s not black and white. Others can and will disagree and want to be pedantic. I’ve been a professional dev for 35 years, devs love to argue abt this shit. permalink fedilink source parent hideshow 1 child comment replies: [–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent [–] tempest@lemmy.ca 3 points 1 year ago Depends on the verb and the application. If the string is valid 200, if it isn't 400, 404. permalink fedilink source parent [–] thesmokingman@programming.dev 3 points 1 year ago It’s still just another type of ID so you can do lookups on it. Nothing would change. UUIDs are used all the time. permalink fedilink source parent
[–] Aatube@kbin.melroy.org 3 points 1 year ago* (6 children) how should a REST API respond to the client sending a URL the ends in a string instead of a numeric ID? like api.social/users/ceeforayteen instead of api.socail/users/11037 permalink fedilink source parent hideshow 6 child comments replies: [–] locuester@lemmy.zip 8 points 1 year ago (3 children) I would do a 400 (Bad Request). Then, with varying amounts of detail depending on the scale of the project and the framework capability, the response body would be something like: { “error”:true, “reason”: “validation”, “detail”: “user id should be numeric” } permalink fedilink source parent hideshow 3 child comments replies: [–] Aatube@kbin.melroy.org 2 points 1 year ago (2 children) that's what i would do too—a JSON response. or is that not what "JSON API" means? permalink fedilink source parent hideshow 2 child comments replies: [–] locuester@lemmy.zip 3 points 1 year ago* (last edited 1 year ago) (1 child) A RESTful service is (usually as of today) a JSON API. They aren’t mutually exclusive things. There’s no black and white definition there. However, when someone is creating a RESTful service, they’re stating that they’ll be paying mind to HTTP Verbs and status codes as a fundamental part of their design. In the original image posted, that dev clearly wasn’t paying mind to the HTTP layer and as such a commenter called it just a “JSON API”, which is the catchall, ugly, Wild West, typical way of doing things (always return 200, errors are in the json). Once again tho, it’s not black and white. Others can and will disagree and want to be pedantic. I’ve been a professional dev for 35 years, devs love to argue abt this shit. permalink fedilink source parent hideshow 1 child comment replies: [–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent [–] tempest@lemmy.ca 3 points 1 year ago Depends on the verb and the application. If the string is valid 200, if it isn't 400, 404. permalink fedilink source parent [–] thesmokingman@programming.dev 3 points 1 year ago It’s still just another type of ID so you can do lookups on it. Nothing would change. UUIDs are used all the time. permalink fedilink source parent
[–] locuester@lemmy.zip 8 points 1 year ago (3 children) I would do a 400 (Bad Request). Then, with varying amounts of detail depending on the scale of the project and the framework capability, the response body would be something like: { “error”:true, “reason”: “validation”, “detail”: “user id should be numeric” } permalink fedilink source parent hideshow 3 child comments replies: [–] Aatube@kbin.melroy.org 2 points 1 year ago (2 children) that's what i would do too—a JSON response. or is that not what "JSON API" means? permalink fedilink source parent hideshow 2 child comments replies: [–] locuester@lemmy.zip 3 points 1 year ago* (last edited 1 year ago) (1 child) A RESTful service is (usually as of today) a JSON API. They aren’t mutually exclusive things. There’s no black and white definition there. However, when someone is creating a RESTful service, they’re stating that they’ll be paying mind to HTTP Verbs and status codes as a fundamental part of their design. In the original image posted, that dev clearly wasn’t paying mind to the HTTP layer and as such a commenter called it just a “JSON API”, which is the catchall, ugly, Wild West, typical way of doing things (always return 200, errors are in the json). Once again tho, it’s not black and white. Others can and will disagree and want to be pedantic. I’ve been a professional dev for 35 years, devs love to argue abt this shit. permalink fedilink source parent hideshow 1 child comment replies: [–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent
[–] Aatube@kbin.melroy.org 2 points 1 year ago (2 children) that's what i would do too—a JSON response. or is that not what "JSON API" means? permalink fedilink source parent hideshow 2 child comments replies: [–] locuester@lemmy.zip 3 points 1 year ago* (last edited 1 year ago) (1 child) A RESTful service is (usually as of today) a JSON API. They aren’t mutually exclusive things. There’s no black and white definition there. However, when someone is creating a RESTful service, they’re stating that they’ll be paying mind to HTTP Verbs and status codes as a fundamental part of their design. In the original image posted, that dev clearly wasn’t paying mind to the HTTP layer and as such a commenter called it just a “JSON API”, which is the catchall, ugly, Wild West, typical way of doing things (always return 200, errors are in the json). Once again tho, it’s not black and white. Others can and will disagree and want to be pedantic. I’ve been a professional dev for 35 years, devs love to argue abt this shit. permalink fedilink source parent hideshow 1 child comment replies: [–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent
[–] locuester@lemmy.zip 3 points 1 year ago* (last edited 1 year ago) (1 child) A RESTful service is (usually as of today) a JSON API. They aren’t mutually exclusive things. There’s no black and white definition there. However, when someone is creating a RESTful service, they’re stating that they’ll be paying mind to HTTP Verbs and status codes as a fundamental part of their design. In the original image posted, that dev clearly wasn’t paying mind to the HTTP layer and as such a commenter called it just a “JSON API”, which is the catchall, ugly, Wild West, typical way of doing things (always return 200, errors are in the json). Once again tho, it’s not black and white. Others can and will disagree and want to be pedantic. I’ve been a professional dev for 35 years, devs love to argue abt this shit. permalink fedilink source parent hideshow 1 child comment replies: [–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent
[–] 0x0@lemmy.zip 2 points 1 year ago devs love to argue abt this shit. Tabs vs spaces comes to mind. permalink fedilink source parent
[–] tempest@lemmy.ca 3 points 1 year ago Depends on the verb and the application. If the string is valid 200, if it isn't 400, 404. permalink fedilink source parent
[–] thesmokingman@programming.dev 3 points 1 year ago It’s still just another type of ID so you can do lookups on it. Nothing would change. UUIDs are used all the time. permalink fedilink source parent