2022-02-22 Meeting notes

Requirements

-Sends, get a report.

-It will handle email invoices correctly → in each case. What should be in it. not implementation – have XML - how and where. e.g. valid and error.

Output :

• If there is any communication error. it is preferable that your service reacts with a human-readable message

• User stories

• Functional and Non-functional

If the API works → functional.

error handling, well laid out - non functional

-specification rather than implementation - how the user behind the scenes will interact with it.

Constraints

• explain all the requirement of the constraint

• Constraint on us or the system? → e.g. time of development (on the coder) 

• Constraint on how big the file can be 

• Constraint of the format 

• Blocker / roadblock – how we go about it. are we choosing the ignore> - time constrains e.g. email is difficult – we could discuss what makes it difficult and why. If we can make compromises then we can try. Some file formats aren't as easily acceptable , then only choose a few.

• Explain the decision making.

XML

• Look at contents via code –>

• DO an XML file and post it on the website.

• Send XML file on the email

• Do not store it publicly on a link – private source.

• Done / automated via code. Send via a text message. invoice rendering.

• Send via text message - can support multiple formats.

Invoice Sending API

e.g. Have a PDF and upload to google drive

Sends it

Checks that there is an error

Produces the Report (get a response back)

Also need to have an endpoint - i.e. a status e.g. a ping back, give a general report.

Usability and documentation. Maximise mark.

Send the XML code in the email.

Make it do SMS, Email etc etc

In this report → communication report → Confirmation e.g. success. Regex.

Building the API this deliverable. In the next one, we use other APIs to build an app.

Endpoint

Health of the API check. E.g. heartbeat that is a ping. The uptime, last invoice sent. how long did it take to send.

• HTP request.