Random Learnings by Ralph Palomar

     Handling and processing large files via API can sometimes be challenging because the bytes of data need to be encrypted and sent over the network, which may have some bandwidth and security restrictions. However, in my experience it is still possible to send a moderately large file (less than 5 MB) using multipart/form-data POST request in Mule. This is possible because Mule supports streaming of data, which simply means that the whole data is NOT being read and loaded into memory; rather, the data are being read by chunks or buffers of a specific size in an efficient way. The HTTP Listener endpoint is one of those endpoints that support streaming. More technical details here .     File transfers of moderately large file size can be done in Mule. For very large files, I haven't explored this yet, but the most common solution in the past is using the secured FTP transfer. File transfers of very large files via API may be possible but may require a lot more worker size (maybe 1

 What is a Media Type?        Media Type is also known as MIME type, which stands for Multipurpose Internet Mail Extensions. It is a two-part identifier for file formats and contents transmitted over the Internet. Since APIs are network applications that are using the HTTP transport, media types are the identifiers that describe the request and response format that the API consumes and produces. You can indicate the media type in these HTTP headers: Content-Type and Accept. A common example of a media type is text/html; charset=UTF-8 , wherein text is the type and html is the subtype, which may also have optional parameters such as charset that indicate the character encoding, e.g. Unicode (8-bit, 16-bit), ASCII, etc.     Mule supports a lot of media types, not just XML or JSON. As per the MuleSoft documentation, below are the supported media types:     The great thing with Mule is that it is data agnostic, as long as you use one of the media/ MIME types in that list. Once the request

Exposing an API to be consumed by client applications entails a lot of challenges. Apart from a good API definition and documentation, you also need to ensure that the request payload submitted to your API endpoints are valid and conforms to the expected data structure. Although it is not required, I think some of the advantages to validate a request payload are: Establish a service contract which is a form of agreement between the service provider and the service consumer. This means that, in order to successfully consume an API, a client application needs to strictly follow a specification "for the request payload" called a data schema . Establish data integrity which ensures that all incoming data submitted to the API are "in a format that is expected". It doesn't make sense to process malformed data. For instance, if you are inserting data to a relational database, it would be more beneficial to first check mandatory (or required) fields before processing th