[swift-server-dev] HTTPMethod, was: Re: Next HTTP API meeting

Logan Wright logan at qutheory.io
Thu Mar 23 07:35:23 CDT 2017


I think it might be lowercase to stick w/ the official Apple swift 3
guidelines, but definitely agree on some type of extensibility. Currently
I've been naming that 'other' in general. With that said, that's kind of
why I included a String in my proposal. If we can focus on the actual
components of the parser and let users define models as much as possible,
then it offloads a lot of our opinions into respective frameworks. In terms
of Method, here's how I currently have it for discussion:

enum Method {
    case get, post, put, patch
    case other(String)
}

I think in addition to adding new official methods (I might be wrong here,
need to double check) but I believe server/clients can define any method
they might want to use between them, so I completely agree with you that
whatever we have will definitely need some type of extensibility (whatever
we call it) to conform to spec.

On Thu, Mar 23, 2017 at 12:12 PM Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

> On 23 Mar 2017, at 11:18, Logan Wright via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> > some types that I think are pretty unambiguous like HTTPMethod
>
> May I ask how that would look like in your opinion? I was thinking about
> that too, and I find it rather hard to come up with a really good solution.
>
> The desirable thing would be an enum, but such can’t be extended in Swift
> w/o an associated value. Like so
>
>   enum HTTPMethod {
>     case GET, REPORT, MKCALENDAR, CHECKOUT, …
>     case ExtendedMethod(String)
>   }
>
> But I think this would be pretty weird for ‘late’ methods and you’d end up
> with code like
>
>   switch method {
>     case .get: ...
>     case ExtendedMethod(“PATCH”): ...
>   }
>
> which will look really weird quickly. New methods do not come around every
> day, but more often than you might think (note explicit support for
> arbitrary ones in todays XHR, this used to support only GET/POST, hence the
> xhr-method header thing).
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170323/83e1fd48/attachment.html>


More information about the swift-server-dev mailing list