Discussion for announcement "MVC's action result naming changes" #4118
Comments
I am using RC1 and I personally miss few result types:
Is there any discussion why few of these response types are implemented, while others are not? |
@zygimantas some context to the |
Just Google "http 403" . It should be forbidden IMO. Also +1 for 405 and 409. Those make sense |
@pranavkm thanks, it makes sense in general, but it conflicts with other response types, which are named accordingly to HTTP status codes. I would choose "Forbidden" name, no matter what name Right now, I must use 3 different notations in a single project:
Something like this might give more consistency: StatusCodeResult(
int statusCode,
object content = null,
collection_type? headers = null,
int? subStatusCode = null) And there might be an enumeration or class with constants which would translate readable status codes to int, i.e: Related issue: aspnet/HttpAbstractions#174 |
Is there a particular reason that the |
Thanks for making it more consistent. I also agree with @zygimantas that it should be "Forbidden". In the |
This was never applied consistently in MVC or WebAPI. We started out trying to be consistent with the past releases (to avoid breaking your code), and embraced the fact that weren't ever consistent about it in previous versions. However, we've continued to get feedback about it to the point where it seemed worth the break. Given a choice, we'd pick less boilerplate over more, so we dropped the prefix. |
Good example.
If there is not real benefit, I would choose for one which is most used - that is with the prefix in previous ASP.NET versions. |
Building on @zygimantas and @304NotModified, I would like to see a |
@rynowak I understand the desire for less boilerplate, but having prefixes that cause all those classnames wasn't just boilerplate, it helped people find them. I agree with @tuespetre - if the status code names are going to be harder to discover in intellisense/autocomplete (and they are now), then we should at least have an easier way to indicate a status code directly. |
One thing isn't fully clear to me. Are those exceptions always bind to a http status code? If so, then prefixing the "http" isn't bad IMO as the namespace (Microsoft.AspNetCore.Mvc) isn't containing "HttpStatuses" or something like that. (edit, maybe I have to rename my username ;)) |
In my opinion Visual Studio should sort all the possible options based on what's the most appropriate / likely item. For example, if you're in a function that returns IActionResult then it should first list all the available methods or classes that actually implement IActionResult. Kind of silly to show everything in alphabetical order... |
Closest user voice I could find: |
The lack of consistency here is really frustrating. The status codes all have well defined names so naming seems like a non-problem. If other parts of the framework name things counter to the RFC and can't be changed for compatibility reasons that is fine but I think it is far more important for users to have some way to rely on consistent naming within a given context. When in the context of writing a For example, if I want to return an There are relatively few status codes out there and they are all pretty well defined (at least as far as naming goes). It seems like it would be a pretty easy task to simply provide a set of result wrappers (like
At this point I have a reasonably strong desire to just not use the framework supplied IActionResults and build my own set of helpers that are at least consistent. |
Yes, please make it consistent. |
We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have. |
Discussion issue for aspnet/Announcements#153
The text was updated successfully, but these errors were encountered: