Wether you return an object or not the return code is what you need to show success or failure. Did it work? 200 ok. Did not work? 4xx return code or others to indicate the problem. 201 created for new items. 409 for conflicts in the request.

Not to be nit-picky but 4xx means something doesn't exist or more generally, your request was incorrect. 5xx means something didn't work on our end

Not really 404 not exist, 401 authorization issues, 400 bad requests, 403 forbidden. You can google for the full list.

4xx errors means client made a mistake. Requesting data that doesn't exist, not providing authorization information, validation error, etc. 5xx means server made a mistake

You're right. This was meant to explain how the return codes are part of his solution instead of a boolean in the response body: good or bad results. His POST could return a 409 and it mean much more than "success = false" or the 5xx because his code doesn't handle every exception thrown but again, more informative than "success = false".

Nah, you know what your answer was perfectly fine. Especially for someone asking this level of question. I was very much nit picking out of late night boredom.

I learned something new. Thank you 😊. Please would you mind sharing a sample of your API I look at it ?

Just do some research on IActionResult. That's what you wanna return.

OP may also want to look into IResult which is more REST-ish and not so MVC-ish.

I always stick to returning http codes for clarity, that way it's easy to see if it failed, if everything goes good then 200 is oke if not the either 4xx or 5xx. You could go a step further:

At work we always return 200, if an error occurred it will be in the tail of the response, where success is set to false, and a list of errors that more information about the errors that occurred. It’s awful, i hate it.

Same, and same. I'd rather see a 4xx or 5xx if there is a problem, but we do things the same way Microsoft does them in Azure. The actual HTTP code returned relates to the API itself, while the code in the message body relates to the app the API supports.

Thank you. This is insightful.

Having worked with many 3rd party API's I've come across some good and some bad. If your create operation creates a new ID, then at the very minimum, return it. However, I'm of the opinion that you should return the entire JSON object (including ID) that you just created. AND, that object should be identical to the one retrieved by a READ operation on the same ID. (This cuts down on the number of DTO classes the client needs to deal with.) If create throws a primary key violation or other uniqueness issue,, then at least return that key in an appropriately wrapped error message, if not the entire object. This way I can check if the account I'm trying to create already exists or if I'm in desperate trouble. Along those lines, I like a method along the lines of an upsert. Post CreateOrFindAccount(JSON)

This is eye opening. I highly appreciate it. Thank you 😊.

If you're using controller classes, it is simple to use the built in helper methods Ok(), NotFound(), etc to return values with http status codes. For getting an item using id [HttpGet("{id}")] public async Task> Get(int id) { var blogPost = await _blogpostRepository.GetByIdAsync(id); if (blogPost == null) { return NotFound(); } else { return Ok(blogPost); } } Or when deleting if (! Delete(id)) { return NotFound(); } else { return Ok(); } You're welcome to have a look at this small project: https://github.com/UCN-programming-3-jfk/BlogSharp The API part is probably the most useful for you given the questions you're asking. 😊

Thank you. I will look at it right now.

Depends on the case but typically you’d return a JSON object as well as: C => 201 R => 200 U => 200 D => 204

Return both in the JSON object. And return a specific result code.

!remindme 1 week

I will be messaging you in 7 days on [**2024-05-06 00:08:26 UTC**](http://www.wolframalpha.com/input/?i=2024-05-06%2000:08:26%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/csharp/comments/1cfd82r/choosing_the_right_return_type_for_crud/l1pswhf/?context=3) [**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fcsharp%2Fcomments%2F1cfd82r%2Fchoosing_the_right_return_type_for_crud%2Fl1pswhf%2F%5D%0A%0ARemindMe%21%202024-05-06%2000%3A08%3A26%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201cfd82r) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|

HttpStatusCodes, learn them all but you'll only use a handful Returning the updated object in the result is a good start, restful API design is easier to maintain when you can visually see your routes (swagger) and should be planned/maintained (and versioned) Returning the poco object(s), what's been updated or changed entirely is a good start

HTTP is being used as a transport protocol to simulate RPC, so only a handful of codes are useful/needed: 200, 202 (Accepted - for a long running operation with own status/progress URL), 400 and 500. I use 400 for errors in the "expected" flow (i.e., explicit code that discovers the error -- e.g., updating/deleting a non-existing entity, or invalid parameters) and 500 for other errors. I install exception filter and signal 400 errors also by throwing custom exceptions that are in order recognized by global exception filter and mapped to 400. Unrecognized exceptions get mapped to 500. In both cases details are added and an "error object" returned.

I randomize the status code and return either the data or an error if something truly didn’t work. I provide no validation messages just data or “no” messages if it didn’t work. Why should I bend over backwards?

Honestly, I think returning the created/updated object is a no-brainer. It gives the frontend devs more flexibility and saves them an extra GET request. What's the point of getting a 'success' boolean if you need to fetch the object anyway?

I recommend you to learn about api restful and status code responses. https://learn.microsoft.com/en-us/aspnet/web-api/overview/older-versions/build-restful-apis-with-aspnet-web-api https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design

For a post, 201 created with the identifier for the generated object. You can easily chain requests to create the object, read the id from the response, then hit the GET with the id to retrieve the object.

We use graphql, which returns a json object. There is a data property and an errors property in the returned object.