What's the reason for having a `json` and `xml` part?

[ThomasLandauer]

While thinking about module's parts in general (see https://github.com/Codeception/Codeception/issues/6026), one thing is still unclear: What's the reason for having the two parts in this module? Are there really situations where loading the entire REST module would lead to a conflict?

And what does it mean that e.g. at https://codeception.com/docs/modules/REST#amBearerAuthenticated both parts are listed? That you'll get this method if you load part json or xml or the entire module (i.e. no part key given at all)? => This is inconsistent with https://codeception.com/docs/modules/Symfony where part is not mentioned for most functions.

[Naktibalda]

I remember that the idea was that if somebody is testing webservice which returns JSON, they don't need XML methods and vice versa, but they both need amBearerAuthenticated and other action methods. Including only methods you need reduces size of autogenerated Actor class and that should have some positive effects.

[ThomasLandauer]

and that should have some positive effects.

On speed? The question is if that's worth it...

In total, I'm suggesting to drop those two parts here, for the following reasons:

• Consistency: Right now, I'm trying to explain the "part" system in the docs, as a means to prevent compatibility problems - see https://github.com/Codeception/module-webdriver/pull/33. But this is not true for the REST module: Here, the same thing (parts) is used for a different goal (speed).
• Effectiveness: I'm counting 9 XML-related methods at https://codeception.com/docs/modules/REST. And I can't believe that the additional complexity (one more thing to pay attention) is worth the (minimal) benefit of reducing the generated actor classes by just 9 methods.

I mean, it's the nature of a library that not everybody is using every function: lib-innerbrowser has some Ajax methods that I don't need if my app doesn't do Ajax; and some Iframe methods; framework modules have Email methods, etc...

[Naktibalda]

I think that the REST module had parts first, probably before I started using Codeception. So this is the original purpose. Parts functionality was reused to solve module conflicts around 2.2.