{"push_id":684897227,"size":6,"distinct_size":1,"ref":"refs/heads/master","head":"d654ccaf3dda440475b3f1affee6731a67fe26bd","before":"2725e20a1a219a9c394b1d3684e03ae3a1dc1ee1","commits":[{"sha":"f9b1e7fc5020fc9c9f0928d2baca46719596b499","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@well-typed.com","name":"Andres Loeh"},"message":"Switch server interpretation to a datatype for efficiency.\n\nInstead of directly interpreting a server as a `RoutingApplication`,\nthis change introduces the concept of a `Router`, which is a datatype\nwith several constructors.\n\nIn particular, the type of the `route` function changes from\n\n    route :: Proxy layout -> Server layout -> RoutingApplication\n\nto\n\n    route :: Proxy layout -> IO (RouteResult (Server layout)) -> Router\n\nMost important in practice is the case of the `StaticRouter` constructor\nin `Router`. For choices between statically known paths, we can now use\na lookup table to dispatch requests rather than trying each request\nindividually.\n\nThis brings down routing complexity of a common case from\nO(n) to O(log n).\n\nAnother important change is that the handler that is passed down by\n`route` is no longer of type `Server layout`, but of type\n`IO (RouteResult (Server layout))`. This means that API constructs\ncan \"delay\" checks and failure. For example, `ReqBody` does not have\nto fetch the request body and feed it to the handler immediately; it\ncan instead record these actions in the handler that is passed down.\nThe code will only be executed at a leaf / endpoint of the API.\n\nThis is desired behaviour: We prefer to save work by doing all matching\non static path components first. Furthermore, we get better error codes\nby doing so.","distinct":false,"url":"https://api.github.com/repos/haskell-servant/servant/commits/f9b1e7fc5020fc9c9f0928d2baca46719596b499"},{"sha":"404bfdd89cc5d5949021341ad25d6126dcfdf39a","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@well-typed.com","name":"Andres Loeh"},"message":"Add test cases for the priority of error codes.\n\nDue to the delayed treatment of checks during the server interpretation,\nwe now have the ability to produce \"better\" error codes for certain\nAPIs. This change introduces test cases for some of these situations and\ntheir new, desired results. These tests would mostly fail with the old\napproach to routing.","distinct":false,"url":"https://api.github.com/repos/haskell-servant/servant/commits/404bfdd89cc5d5949021341ad25d6126dcfdf39a"},{"sha":"e83397a1db504ee4195ee3f951c27588108e335d","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@well-typed.com","name":"Andres Loeh"},"message":"Fix the auth combinator example.\n\nThis change adapt the auth combinator example to the new router code.\nIn general, the server interpretation of user-written combinators will\nbe affected by the new routing code.\n\nThe change here also introduces a change in functionality: previously,\nwrong authentication triggered a \"hard failure\", whereas we now trigger\na \"soft failure\", which is recoverable. For the simple example, this\ndoes not make a lot of difference.\n\nIn general, I think having a soft failure is the right option to take\nhere, although we want a more general story about the relative\npriorities of different error codes.","distinct":false,"url":"https://api.github.com/repos/haskell-servant/servant/commits/e83397a1db504ee4195ee3f951c27588108e335d"},{"sha":"eb86a821059d9f6827972afe5155614b411d5138","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@well-typed.com","name":"Andres Loeh"},"message":"Refactoring: one module per concept.\n\nThe main `Server.Internal` module was getting a bit large for my taste.\nIt now contains just the instances. All the administrative utilities\nare in their own dedicated modules.","distinct":false,"url":"https://api.github.com/repos/haskell-servant/servant/commits/eb86a821059d9f6827972afe5155614b411d5138"},{"sha":"31b12d4bf468b9fd46f5c4b797f8ef11d0894aba","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@well-typed.com","name":"Andres Loeh"},"message":"Refactoring: abstracting common parts of method handlers.\n\nThis change makes an attempt of abstracting out some of the common\nfunctionality found in the handlers for the different request methods.\nThere's still a bit of code duplication between the cases for headers\nand no headers and empty responses. But it's a significant relative\nimprovement already.","distinct":false,"url":"https://api.github.com/repos/haskell-servant/servant/commits/31b12d4bf468b9fd46f5c4b797f8ef11d0894aba"},{"sha":"d654ccaf3dda440475b3f1affee6731a67fe26bd","author":{"email":"2728eb9470dece58242931df7a4700589c3c0006@gmail.com","name":"Alp Mestanogullari"},"message":"Merge pull request #111 from haskell-servant/improved-routing\n\nImproved routing","distinct":true,"url":"https://api.github.com/repos/haskell-servant/servant/commits/d654ccaf3dda440475b3f1affee6731a67fe26bd"}]}