Expose 'POST' request to REST API

[rishighan]

Is your feature request related to a problem? Please describe.
No it's not related to any problem.

Describe the solution you'd like
I'm the developer of a comic book curation app called ThreeTwo

I find Metron as the most pragmatic and scalable solution for comic book metadata outside of ComicVine. That said, I was wondering if you would be open to the idea of ThreeTwo allowing its users to add comic book metadata straight from ThreeTwo to Metron, with all the necessary fields. The most obvious benefit of this approach is that contextually, the users' library is managed within ThreeTwo, so it would make sense for the metadata to "sync" with Metron, loosely speaking.

Implementation-wise ThreeTwo would simply talk through an API exposed by Metron with authentication, and would push it into whatever moderation mechanism Metron has in place.

Conceptually speaking I think this would be a win-win for both ThreeTwo and Metron.

Additional context

Screenshots here on Discord: https://discord.com/channels/895398178092900412/895398178092900416/897151450910703637

[bpepple]

I'm not opposed to adding a 'POST' request to the REST API, but I would be unlikely to give that access to everyone since the potential for creating a mess is pretty high. That's why almost no data repositories (Comic Vine, League of Comic Geeks, Wikipedia, etc) exposes that method. If I were to implement it, I would most likely only grant it to folks who have a track record of good editing, so you don't have problems like adding copyrighted material, duplicate entries, etc, to the database.

Now to implement a 'POST' request isn't terribly hard, it would pretty much only need to change the ViewSets from it's current ReadOnlyModelViewSet to a Custom ViewSet like this for each resource (with permission restrictions (admin, editor) added to the create operations):

class CreateListRetrieveViewSet(mixins.CreateModelMixin,
                                mixins.ListModelMixin,
                                mixins.RetrieveModelMixin,
                                viewsets.GenericViewSet):

[rishighan]

Thanks for that thoughtful response! I agree with your assessment that the editing capabilities should be restricted to a limited set of contributors, based on some criteria. I alluded to that in passing when I mentioned "authentication" in my issue.

Regarding the PUT request, I'm open to whatever implementation you have in mind. From a UX perspective, it will be transparent to the user in ThreeTwo.

Regarding limiting access to trusted contributors, is this something you have planned to implement or something that already exists? The credentials ThreeTwo passes in the request can have a mapping of roles within Metron that can determine if the user is allowed to edit/add content?

[bpepple]

Regarding limiting access to trusted contributors, is this something you have planned to implement or something that already exists? The credentials ThreeTwo passes in the request can have a mapping of roles within Metron that can determine if the user is allowed to edit/add content?

Django's authentication system has a groups model which is what I'd use to grant permission for Post requests.

Users that have valid account authentication, but not editor permission would receive a HTTP 403 Forbidden response.

Users that don't have valid account authentication, would receive a HTTP 401 Unauthorized response.

[rishighan]

I like that. My own app is built using Typescript. I can stand up a microservice to auth against the Metron API and make calls to it. Is there some documentation or Swagger or anything that I can use to start a scaffold?

[bpepple]

Current api docs are located here: https://metron.cloud/docs/

[rishighan]

Thanks! I'll keep this "rfc" open so we can track all the important details.

[rishighan]

@bpepple I looked at the "Edit" page for a series, and tried to infer the fields I need to make available to be edited by users in ThreeTwo.

Do you have a formal schema that I can look at?

I use mongo as my data store and for metadata providers such as Metron, I plan to maintain all the information in a sub document.

My current schema looks like this:

https://github.com/rishighan/threetwo-import-service/blob/master/models/comic.model.ts

[bpepple]

@bpepple I looked at the "Edit" page for a series, and tried to infer the fields I need to make available to be edited by users in ThreeTwo.

Do you have a formal schema that I can look at?

Do the schemas in the docs (bottom of page) not provide the info you're looking for?

https://metron.cloud/docs/

[rishighan]

Thanks @bpepple !

[rishighan]

Hello @bpepple I finally got around to fetch some information from the Metron API, and present it in the UI. It all went swimmingly and thanks for the beautiful documentation!

Now, specifically about the response of /api/series, the response is roughly this:

  {
      "id": 1623,
      "__str__": "Wolverine: Black, White & Blood (2021)",
      "modified": "2021-02-07T11:10:03.192288-05:00"
    },

I am curious as to why the key for what seems to be the name of the series, is __str__. In my implementation I am trying to genericize the method that makes the Metron API calls, so that I can just tell it to fetch a resource, say, publisher or series or character and then I massage the data, which means, I take the response and set it in the local state.

To that end, I wanted to ask: is it feasible to change __str__ to name in the response for /api/series ?

If not, I would just like to know the rationale for my information, and I can work with __str__ if its too much work to change it.

[bpepple]

The __str__ method is used for the display name for an object, and is not the same as the db field name. In your example above, the name field would be Wolverine: Black, White & Blood. The reason I used the object display name is to easily differentiate multiple results (for example if someone where to do a series query for Batman).

To fix this I would probably need to add the name, year, and volume field to the serializer (and possibly removing or renaming __str__ to something like display_name)

In the future, it might be worthwhile to have API Improvements threads in the Discussions page to keep different items separated.

[rishighan]

Thank you! I will move this request to the Discussions thread.