API Designer, Mulesoft and cloud services


#1

(warning this is an opinionated criticism of API Designer current state)

API Designer is a splendid tool for building RESTful APIs and the current best tool for editing RAML.

However I am concerned by the way API Designer is seamlessly integrated with the MuleSoft cloud services (storage and mocking service). At the moment if anyone wants to use API Designer for a project, and doesn’t want to share it with Mulesoft, it is necessary to manually tweak API Designer (brianmc/raml-store and read API Designer source code) to effectively disable all cloud services which could “accidentally” send information to the MuleSoft third party.

I hope in a close future MuleSoft will try to separate their offer of great open-source tools for RAML from any of their cloud services. Plugins for those kind of features are maybe the way to go.

Currently if I want to use RAML without sending the specification to a third party, I unfortunately have to do without the best tool for editing RAML (also because it is not file based and thus not possible to use a SCM tool).


#2

Hi @d500,

thanks a ton for your feedback. I’ll definitely make sure it reaches the right people :wink:

Cheers,
Christian


#3

Thanks for bringing it up, @d500, and for following up, @christian_vogel.

The standalone API Designer, which you get from github, does not in fact use MuleSoft’s cloud offering for storage: the built-in storage engine uses your browser’s localStorage, and you can extend it to do something else via available plugins. Only when it’s embedded in MuleSoft’s product offering (Anypoint Platform) does it get extended to save using our cloud service, and you know that because only then do you need to login to the Anypoint Platform ;-).

As for the mocking service: yes, indeed, it does hook into our mocking service, though that’s currently offered just as a standalone service without any requirements about user authentication (into the Anypoint Platform or anywhere else). That’s purely for convenience: users find the service useful, and it’s not available for downloading and running independently, so in the github source we have it pointing to the mocking service. You don’t have to use it – just don’t turn it on in your API Designer UI.


#4

Thanks for the response and clarification @usarid.

You are entirely correct about the storage and mea culpa I confused requests to the mocking service when saving document in API Designer. (when Mocking Service is on, every save operation will trigger a PATCH request to the services, but no request is made when mocking service is disabled).

I understand completely the great usability of the mocking service for users. However the feature is, as you said, built-in in the API Designer. When I say “accidentally” I also mean an user error which could send private work to your servers. Your response of “it’s here, if you don’t want it don’t use it” is oversimplified. With this situation there is no clear delimitation between what is open-source/standalone and what is not. Yes API Designer is open-source but one convenience feature happen to send data to a third party proprietary software. Even if the others features are truly open source and doesn’t need a third party proprietary software, I hope the mocking service will remain an exception rather than the rule. Some people (and surely the majority) see this feature as a convenience, others (devil’s advocates) could see it more as a forced usage of third party proprietary software and possible disclosure of sensitive information.