Issue 2 retire rolling parameter in api decorator #41
Conversation
Change GET to PATCH in service listing for the password-reset endpoint.
Finish its docstring parameters.
There was a problem hiding this comment.
Looking pretty good - almost there :)
- it would be good to add a line to the overall changelog, but I'm not sure it exists already in this branch. Maybe you'd merge main into this one anyways when you deal with merge conflicts ...
- The chosen name for the new field (
prior) makes most sense when used for GETting data (as a query parameter). For POSTing, a bit less so (for me). How about using the nameknown_at?
|
I'd like to keep the name for the prior field for now. Terminology is a big issue in itself. We can revisit the name later if needed, but I would like to keep terminology consistent across FlexMeasures (also with respect to other fields) and that deserves a discussion of its own. |
|
Keeping terminology consistent would require discussing a term well before merging the PR that introduces it to main, no? |
|
The "prior" field is already used on main denoting the equivalent concept for GET requests, so for me, keeping terminology consistent is naming this field for POST requests the same. I cannot follow up on your suggestion for renaming the prior field for POST requests without a discussion of renaming the equivalent field for GET requests, too, as well as the closely related "horizon" field used for both GET and POST requests. |
|
I overlooked that it is on main already. Go on and merge. Let's briefly discuss my naming idea in person / on the phone. |
In this PR we:
I plan to update all of the API endpoints for POSTing data (meter data, prognoses, prices and weather data), but first I want to get the hardest one right: postPriceData, which forces me to take into account knowledge horizons properly. You probably have some good API coding tips for me at this point already, concerning the use of marshmallow perhaps, before I move on to the other endpoints.