Failure, APIs, and Error Conditions

  • Due No Due Date
  • Points 13
  • Submitting a file upload
  • Available after Feb 4, 2021 at 7am

Part 1: Add/Drop API

Suppose you are designing an API to process class adds and drops for BYU. The basic form of the URL is

/classes/:cid/students/

where :cid is the class ID.

Performing a POST on this URL with a body that includes a student ID would add the student to the class.

Performing a DEL on this URL with a student ID as a suffix drops the student from the class like so

/classes/:cid/students/:sid

where :sid is the student ID.

In most cases, the system will return a 200 status code signifying that the action has been taken and all is well.

But what happens if something goes wrong?

Consider the following scenarios:

  1. A POST is made to add a class for which
    1. the student doesn’t have the proper prerequisites.
    2. the class is full and the student needs an add code

In these cases, the add cannot happen.

  1. A DEL is made to drop a class that is a prerequisite for a course that the student has already registered for the next semester. In this case, the drop can happen only after the postrequisite course is dropped.

Design the responses and draw a state diagram in keeping with the ideas in How to GET a Cup of Coffee for the success condition and each of these error conditions that specifies:

  1. The status code
  2. Any headers
  3. The response body

Ensure that the response body includes information about how the client can make forward progress where applicable. If you use relationship attributes (rel) be sure to define what they mean. In contemplating your solution, ask yourself “what are the reasonable next states in this process?”

Part 2: Conversations

Consider a student process (usually being run by the student, but not necessarily) to add and drop a class using your API. 

Draw a diagram showing the conversations between the student process and the API you designed in Part 1 like the one in Figure 2 of Your Coffee Shop Doesn’t Use Two-Phase Commit. Consider only the case where the class is full and the student must get an Add Code. 

Consider the following questions:

  1. Do you need queues in the interaction between the student and the Add/Drop API? Why or why not? 
  2. How would correlation identifiers be used in the Add/Drop API? 
  3. Are there transactional concerns in adding and dropping classes? Explain.
  4. Are there isolation concerns in this conversation? What is the appropriate solution? 

Submission

Turn in

  • the responses for the four conditions (success and the three failures)
  • your conversation diagram
  • the answers to the preceding questions
0