the ability to return headers in mock requests

[pauldburton]

We have a feature where we make a queue request and it returns a header providing the location of the progress endpoint. This endpoint returns another header with the results endpoint once the processing is completed.

We need the ability to assign those headers to allow our apimock functionality to work again. Would this be possible?

[seriema]

Hmm good question. You can set it to return a status code instead of data. The tricky part here is how you'd set the headers, as the idea is for simple .json files to replace the real API when mocking. Maybe some "meta" object in the .json? Any suggestions on how you'd like to set the headers?

[pauldburton]

our thought was a second file endpoint.headers.json that would have an object of headers to be added to the response. A headers object while also possible has a problem if the response it is a list of objects. Which is why we leaned to a second file. if the file exists included it otherwise forget about it.

[seriema]

Do you always want the exact same headers for every call, without exceptions? That'd be easy enough. The file could be in the API root path. I'm thinking that maybe such things as setting defaults for all calls would be best to do during angular.config instead. The big idea with .json files is that anyone on the team should be able to edit, to make working with the data more streamlined. Would you see this default config in angular instead of .json as a limitation? Overrides would still be possible per call/.json file.

[pauldburton]

for our use case it would be a different response for each call. basically saying where to go next on success.

for example:
/rest/courses/1/students would return /rest/request/1 in the header so the headers json file students.headers.json would be next to the students.get.json file in the course id directory

/rest/request/1 would return /rest/request/1/students on completion of the queued task so the headers file 1.headers.json will be next to the 1.get.json file in the requests directory.

or /rest/request/2 would return /rest/request/2/otherQueuedResponse on completion of the queued task so the headers file 2.headers.json will be next to the 2.get.json file in the requests directory.

The philosophy is defined here in this article. http://farazdagi.com/blog/2014/rest-long-running-jobs/

We do not object to a way to set it globally that could come in handy too if we want to do something with authentication logic and such, but this is our main use case in this instance.

[seriema]

Interesting scenario. From your example and reading that article I understand it as POST /rest/student returns a header with queue info, e.g. queue 123. Subsequent calls would be GET /rest/queue/123 or similar, and get header info about the completed task and it's location, e.g. student 42. So GET /rest/student/42 would return the actual student. I'm wondering if the HTTP verb is valuable enough here to make angular-apimock react to it somehow. Either way, each call had a unique URL which would mean a unique JSON file. By simply adding a header object to them any app could do as it wishes, and one use case would be following the Location until it gets the created resource.

I'm not sure I understand the downside of having the header in the same mock JSON as the response? You mentioned a list of objects, but currently we can only map one API path to one physical file, so if you want to mock a lot of students it'd have to be a lot of JSON files. Solving that could be another feature. Sorry if I'm dense, but maybe you can post an example of how you imagine the contents of a headers.json file so I can better understand why it can't just be a special property on the regular response .json?

[pauldburton]

Sounds about right, though I would make the follow option an optional parameter. The auto redirect would only be helpful if the status code returned is in the 300 range, a location header with a different status code could be for other purposes.

I understand what you are saying about mapping to one file. Headers is something for many other purposes other than our use case, so I know for the integrity of the project, it is useful not to limit yourself to our use case. As a result if the event the endpoint returns an array of objects such as:

[
  {
    "enrollmentId": 1,
    "name": "Daniel Bedoya",
    "sid": null,
    "sectionId": null,
    "percentGrade": 88.58,
    "letterGrade": "B",
    "readyToPost": true
  },
  {
    "enrollmentId": 1,
    "name": "Daniel Bedoya",
    "sid": "L1234567",
    "sectionId": "CNVS0997_01_1202",
    "percentGrade": 88.58,
    "letterGrade": "B",
    "readyToPost": false
  }
]

then a headers object would not be possible.

So our thought to cover all cases would be that the headers.json file would just be an object of headers like it is represented in the $http response object. This could be expanded in the future so each response can define a status code then apps can mock failed responses as well.

{
    "status": 200,
    "headers": {
        "Last-Modified": "Tue, 15 Nov 201512:45:26 GMT",
        "Location": "http://myurl.com/rest/students/42",
        "Authentication" : "Bearer 123jighsd08g79sdf8jsidjf"
    }
}

Another option would be to define the whole response in the endpoint.get.json and then apimock could manipulate the response object in the interceptor.

{
    "headers": {
        "Last-Modified": "Tue, 15 Nov 201512:45:26 GMT",
        "Location": "http://myurl.com/rest/students/42",
        "Authentication" : "Bearer 123jighsd08g79sdf8jsidjf"
    },
    "status": 200,
    "data": [
        {
            "enrollmentId": 1,
            "name": "Daniel Bedoya",
            "sid": null
        },
        {
            "enrollmentId": 1,
            "name": "Daniel Bedoya",
            "sid": "L1234567"
        }
    ]
}

[pauldburton]

any progress in this?

[seriema]

@pauldburton sorry, not really. angular-apimock is pretty simplistic and will just return one .json file for one api request. Your enrolment example pointed out that angular-apimock would have to require an object and not support pure arrays. One option would be to simply not support headers on pure arrays, and requiring a more complex object like you posted for custom responses. So having a separate headers file does make sense in keeping the data json simpler, but it would add an invisible dependency between files and "didn't you read the documentation?" scenarios I'd like to avoid. If you'd like to make a PR then that'd help me out a lot.