Add endpoint for manipulating incident tags only

[hmpf]

The new endpoint lists all tags for an incident with GET, you can POST a new tag or DELETE an existing one and for completion's sake you can GET a single tag.

Works in the swagger-ui sp can be played with there.

The IncidenTagRelation model is hidden away, this endpoint only operates with "key=value"-strings.

To be improved: tests, no hardcoding of the equals-sign, maybe use django-nested-routers instead of manually writing the urls.

[lunkwill42]

Looks good. Couple of comments:

• I get a 500 error and a traceback if I use "invalid" tag syntax for a GET operation, like incidents/42/tags/foo
• I wish you would consider Simplify the tag data structure required by the Incident API endpoint #136 when working on adding tag related APIs. I.e. it's one thing the backend data model for tags is over-engineered, we can still simplify the API and change the backend model later...

[hmpf]

• I get a 500 error and a traceback if I use "invalid" tag syntax for a GET operation, like incidents/42/tags/foo

Yeah that should have a better error code.. 404 might do in this specific case?

• I wish you would consider Simplify the tag data structure required by the Incident API endpoint #136 when working on adding tag related APIs. I.e. it's one thing the backend data model for tags is over-engineered, we can still simplify the API and change the backend model later...

We can't really simplify the API while still being on version 1, but I guess I can make a simplified API for version 2 and make version 2 visible? Then you can adapt the API client library. Different PR, though, that.

One thing I disagree with the designers of drf is nesting. I think that every attribute on a model is also a resource in and of itself, that should have its own endpoint and full CRUD if relevant. An API should hide the implementation, not be a thin veneer on top.

[lunkwill42]

• I get a 500 error and a traceback if I use "invalid" tag syntax for a GET operation, like incidents/42/tags/foo
  Yeah that should have a better error code.. 404 might do in this specific case?

404 is good enough: There is no such tag.

(Either that, or a client error should be issued)

• I wish you would consider Simplify the tag data structure required by the Incident API endpoint #136 when working on adding tag related APIs. I.e. it's one thing the backend data model for tags is over-engineered, we can still simplify the API and change the backend model later...

We can't really simplify the API while still being on version 1, but I guess I can make a simplified API for version 2 and make version 2 visible? Then you can adapt the API client library. Different PR, though, that.

Yes, I agree. This interface is perfectly in line with API v1, but we should add this to #136 or maybe make a comment to #295.

In summary:

• Fix the 500 error (use 404)
• Fix the merge conflict

And: Are we still updating the endpoint docs, now that we have swagger?

[hmpf]

Are we still updating the endpoint docs, now that we have swagger?

The goal should be that we don't have to but it can be fiddly to get the swagger right. Moving the free text docs so that swagger picks up on it would be wise though. (By using docstrings, basically.)

[hmpf]

Invalid tags now lead to a 404, the merge conflict is fixed, and it's rebased on master.

[lunkwill42]

Thank you :)