Staff multi rank / position (Do we need to reorganize data structures?)

[wojteb]

Example: https://myanimelist.net/anime/5/_/characters#staff Okiura, Hiroyuki is Director, Storyboard, Key Animation

In the client I need this divided. Code it for API?

2) This same data have 2 names:

• position from: https://api.atarashiiapp.com/docs/2.0/responses/#person
• rank from: https://api.atarashiiapp.com/docs/2.0/responses/#cast

(and main_role <-> role)

I suggest: Split cast to cast and position, mark the role as deprecated and add position as array. But this not enough good, because in person.anime_staff_positions we have position and detalis.

3) In doc person.anime_staff_positions.anime have 3 fields, in response I have 23 fields

4) 2.1/people/8502 The responses are non-aggregated data. Maybe they should be grouped by anime or position. (But at the position is a problem with the field details).

5) I'm planning write #130: Character endpoint, so I will need data structures for it. (I don't know when. Its depend from my employee)

6) Anime endpoints don't return info about anime: eg: anime/cast/{id}. I change it for me.

7) Wrap response with status data: #136

I know it was not proper to connect the problems, but it is more a starting point for the debate: Do we need to reorganize data structures?

No change is also a good option, but personally I prefer that this is due to conscious decision, not ignorance.

This is more a question as to how long will support branch 2.2 / when you plan to start work on branch 3?

[wojteb]

Changed question, added more examples

[Ratan Dhawtal]

1. Do you mean you want it in an array?
2. Yes, chould be adjusted buy that must be done in API 3
3. Yes, we provide empty arrays and other things so that is why you have 23 fields (which are mostly empty).
4. Yes anime, it will change the output so API 3
5. you can design a structure and send it here or in a separate issue so we could discuss it.
6. We can add support for that but not yet. We have other priorities and want to work at API 3 ASAP.
7. API 3

I know it was not proper to connect the problems, but it is more a starting point for the debate: Do we need to reorganize data structures? Yes API 3

This is more a question as to how long will support branch 2.2 / when you plan to start work on branch 3? https://bitbucket.org/ratan12/atarashii-api/wiki/Roadmap once the roadmap items are completed.

[Michael Johnson]

As a follow-up on Ratan's post, we probably won't be changing major data response formats until a new major release as we don't break compatibility in minor changes. For things where we might be able to just duplicate a renamed item, we may slip it into a minor release if we have time.

1. For right now, split on the comma. Most languages have the ability to do this on strings. We may re-work this for a new additional data structure in a new minor release, or it may wait until the next major.
2. I would support removing the cast data structure and using the person one instead, even if it's a bit more awkward. When combined with some changes, it could work out well.
3. Like Ratan noted, due to internal workings, we sometimes will pass empty values back in response. In general, we try to reuse models where possible to make code less complicated, both the producing side and the consumer.
4. Due to the major changes in response this would require, it will have to wait until a new major. Grouping by an anime title isn't a bad idea.
5. Same notes as Ratan, but please make the structure something we could re-use for the characters in the persons endpoint in a later version.
6. We probably aren't going to add more info to the main anime object that needs data on other URLs. We have other API endpoints that can be called if/when that additional information is needed and otherwise won't use MAL resources if not.
7. Expanding error messages could be looked at in a later major release. We may need to develop a way to return legacy error messages for older API versions, though.

I think some data structures can be adjusted and cleaned up as some parts of the API aren't as well designed as others. We'll need to do that in a new major release, however. Also, we've in some ways put more priority on adding more ways to get/change data than a perfect implementation due to demands of our own application. It's led to some mess at times, but I think it's been kept decently managed. API 3 should be a great place to clean up some of the mess created in API 2.x development.