Add updating devices to apiv1.
We needed a way to be able to update devices after they were created. This is
supported in the devices package, we just needed to expose it using apiv1
endpoints.
In doing so, it became apparent that allowing users to change the Owner of their
Devices wasn't properly thought through, and pending a reason to use it, I'm
just removing it. The biggest issue came when trying to return usable error
messages; we couldn't distinguish between "you don't own the device you're
trying to update" and "you're not allowed to change the owner of the device". I
also couldn't figure out _who should be able to_ change the owner of the device,
which is generally an indication that I'm building a feature before I have a use
case for it.
To support this change, the apiv1.DeviceChange type needed its Owner property
removed.
I also needed to add deviceFromAPI and devicesFromAPI helpers to return
devices.Device types from apiv1.Device types.
There's now a new validateDeviceUpdate helper that checks to ensure that a
device update request is valid and the user has the appropriate permissions.
The createRequest type now accepts a slice of Devices, not a slice of
DeviceChanges, because we want to pass the Owner in.
A new updateRequest type is created, which accepts a DeviceChange to apply.
A new handleUpdateDevice handler is created, which is assigned to the endpoint
for PATCH requests against a device ID. It checks that the user is logged in,
the Device they're trying to update exists, and that it's a valid update. If all
of that is true, the device is updated and the updated device is returned.
Finally, we had to add two new scopes to support new functionality:
ScopeUpdateOtherUserDevices allows a user to update other user's devices, and
ScopeUpdateLastSeen allows a user to update the LastSeen property of a device.
Pending some better error messages, this should be a full implementation of
updating a device, which leaves only the deletion endpoint to deal with.
2 Package trout provides an opinionated router that's implemented
5 The router is opinionated and biased towards basic RESTful
6 services. Its main constraint is that its URL templating is very
7 basic and has no support for regular expressions, prefix matching,
8 or anything other than a direct equality comparison, unlike many
11 The router is specifically designed to support users that want to
12 return correct information with HEAD requests, so it enables users
13 to retrieve a list of HTTP methods an Endpoint is configured to
14 respond to. It will not return the configurations an Endpoint is
15 implicitly configured to respond to by associated a Handler with the
16 Endpoint itself. These HTTP methods can be accessed through the
17 Trout-Methods header that is injected into the http.Request object.
18 Each method will be its own string in the slice.
20 The router is also specifically designed to differentiate between a
21 404 (Not Found) response and a 405 (Method Not Allowed) response. It
22 will use the configured Handle404 http.Handler when no Endpoint is found
23 that matches the http.Request's Path property. It will use the
24 configured Handle405 http.Handler when an Endpoint is found for the
25 http.Request's Path, but the http.Request's Method has no Handler
26 associated with it. Setting a default http.Handler for the Endpoint will
27 result in the Handle405 http.Handler never being used for that Endpoint.
29 To map an Endpoint to a http.Handler:
31 var router trout.Router
32 router.Endpoint("/posts/{slug}/comments/{id}").Handler(postsHandler)
34 All requests that match that URL structure will be passed to the postsHandler,
35 no matter what HTTP method they use.
37 To map specific Methods to a http.Handler:
39 var router trout.Router
40 router.Endpoint("/posts/{slug}").Methods("GET", "POST").Handler(postsHandler)
42 Only requests that match that URL structure will be passed to the postsHandler,
43 and only if they use the GET or POST HTTP method.
45 To access the URL parameter values inside a request, use the RequestVars helper:
47 func handler(w http.ResponseWriter, r *http.Request) {
48 vars := trout.RequestVars(r)
52 This will return an http.Header object containing the parameter values. They are
53 passed into the http.Handler by injecting them into the http.Request's Header property,
54 with the header key of "Trout-Params-{parameter}". The RequestVars helper is just a
55 convenience function to strip the prefix. Parameters are always passed without the curly
56 braces. Finally, if a parameter name is used multiple times in a single URL template, values
57 will be stored in the slice in the order they appeared in the template:
59 // for the template /posts/{id}/comments/{id}
60 // filled with /posts/hello-world/comments/1
61 vars := trout.RequestVars(r)
62 fmt.Println(vars.Get("id")) // outputs `hello-world`
63 fmt.Println(vars[http.CanonicalHeaderKey("id")]) // outputs `["hello-world", "1"]`
64 fmt.Println(vars[http.CanonicalHeaderKey("id"})][1]) // outputs `1`