I'm trying to send xAPI statements from an "Activity Provider" to the ADL LRS live demo. The goal is to implement this from my C# .NET application, but I was having trouble implementing it so I tried running a simple POST request from JMeter.
I do get a 200 response, but when I try to check whether the statement was successfully stored at https://lrs.adlnet.gov/me/statements, it's empty.
Am I completely misunderstanding how this structure is supposed to work? I'm going to install the ADL LRS eventually for testing purposes, but I wanted to get the actual request structure worked out first.
The path looks incorrect, the POST should be to {endpoint}/statements, so in your case it looks like it should be https://lrs.adlnet.gov/xAPI/statements. Additionally you should make sure you are setting the X-Experience-API-Version header. If this doesn't solve the issue, you should look at more than just the response status code, and see what the body contains (and add it to your question). The body for the type of request you are sending should return JSON, with an array with a single statement identifier in it. Additionally when you retrieve the statements the URL you use should match the one that you specify when you send, so /me/ is not correct.
If it is a basic C# .NET project you may be interested in https://github.com/RusticiSoftware/TinCan.NET. It is showing its age, but in general for a number of projects it will still work or would at least be a reasonable place to start.
I am using mocking service feature to build and test API design for one of the POC. I am getting HTTP error code 404, when posting message from design center through mocking service.
See the attached picture as well:
GET, PUT and POST request with without URI parameter are all working fine, but whenever I try to explicitly pass a specific gid or cid with the POST method it is showing the error from above.
I am attaching RAML file:
https://forums.mulesoft.com/storage/temp/6224-test.txt
I have read the documentation and have understood that we can pass any parameter value, when testing API with the mock service.
Could you please help me to find out, why the POST request with a specific gid or cid is returning an error code?
Based on the attached sceenshot you are trying to POST something to the root path of your API Mock Service.
Instead of deleting the parameters and sending the HTTP POST request to an URL like:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/
Please try to keep the URI in the correct format:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/{gid}/channels/{cid}/chatthreads
In this URL you just have to replace the gid and cid parameters in the curly braces to the actual values.
Using your RAML file and a URI in the correct format, like the followine examples:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/10/channels/5/chatthreads
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/10/teams
I am getting "204 No Content":
But when I remove the parameters and try to execute the HTTP POST on the wrong path, then I get "404 Not Found":
Based on the screenshot you have provided; the path to the resource was not complete in your HTTP request. This could have caused the HTTP error code "404 Not Found".
Please make sure that the full path to the resource is set in the API Console. This is needed to be able to identify what resource you want to POST (create).
For details about the usage of special characters (like '-' or '$') in the names of resources; please see the raml-js-parser. This parser is being used by the API Designer.
At the moment there are still open issues related to the handling of special charachters, like '-'. Please see the related bug report: Resource name is invalid: illegal character #129 in the github repository of raml-js-parser.
I would suggest to be using no special charachters in the resource names. (even though the current RFC standards eventually do allow the usage of '$')
According to this; the resource name "$ref" seems to be causing problems in your RAML. Please consider filing a bug report for the API designer in their github repository. However the issue could be caused by the parser as well...
Suppose I ask a question to an criminal register: http://server/demographics/party/{partyId} and that person is not known on that system.
Is that an error? Isn't it a good thing?
When returning 404, it is an error code, Restlet has implemented it as a specific URL cannot be resolved to a route to a server-resource (a handling class), an erroneous situation.
In my opinion, if a system understands a call, and is able to process it without errors, it should return 200 (HTTP-ok), and it should return the information: "We don't know this person".
What is the best thing to do?
There's nothing wrong in returning a 404 status code. It simply means "you asked for a resource, and it doesn't exist". If it did return 200, it would have to somehow return an additional status code telling you that everything went fine, but the resource couldn't be found. That's unnecessary, because 404 already means exactly that.
A status 500 is normally returned to mean "something went wrong, I can't tell you if the resource exists or not". Now if you returned a 404 to mean that, this would be a mistake.
Whether it's a good thing or not is not doesn't have anything to do with HTTP or REST. And BTW, if the register was a file containing the survivors of a disaster, you would probably find it bad to not find the person you looked for, unless maybe if the person is your mother in law, unless you actually love your mother in law. (this is meant as a joke, for those who don't find it obvious).
A web service could be implemented in a way that produces either kind of response.
If it is being implemented in a way that is truer to HTTP/Rest, then '404 not found' would be the appropriate response for not finding something. This is what the 404 status is for.
It may help to think of your request as saying 'I assume this record exists, and I want to see it', and the 404 response as saying 'You are in error that record does not exist'.
If this URL is going to be used by code (rather than be displayed in a browser), then if you don't make a distinction in the response status then you will have to add extra information to the response body to make the difference obvious.
If this URL is going to be displayed to a user in a browser, then the server is still able to display content in the response body for a 404.
Please read: http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1
Quoting:
Conclusion:
Human Readable Error Messages: Part of the major appeal of REST based web services is that you can open any browser, type in the right URL, and see an immediate response -- no special tools needed. However, HTTP error codes do not always provide enough information. For example, if we take option 1 above, and request and invalid book ID, we get back a 404 Error Code. From the developer perspective, have we actually typed in the wrong host name, or an invalid book ID? It's not immediately clear. In Option 3 (DAS), we get back a blank page with no information. To view the actual error code, you need to run a network sniffer, or point your browser through a proxy. For all these reasons, I think Option 4 has a lot to offer. It significantly lowers the barrier for new developers, and enables all information related to a web service to be directly viewable within a web browser.
Application Specific Errors: Option 1 has the disadvantage of not being directly viewable within a browser. It also has the additional disadvantage of mapping all HTTP error codes to application specific error codes. HTTP status codes are specific to document retrieval and posting, and these may not map directly to your application domain. For example, one of the DAS error codes relates to invalid genomic coordinates (sequence coordinate is out of bounds/invalid). What HTTP error code would we map to in this case?
Machine Readable Error Codes: As a third criteria, error codes should be easily readable by other applications. For example, the XooMLe application returns back only human readable error messages, e.g. "Invalid Google API key supplied". An application parsing a XooMLe response would have to search for this specific error message, and this can be notoriously brittle -- for example, the XooMLe server might simply change the message to "Invalid Key Supplied". Error codes, such as those provided by DAS are important for programmatic control, and easy creation of exceptions. For example, if XooMLe returned a 1001 error code, a client application could do a quick lookup and immediately throw an InvalidKeyException.
Based on these three criteria, here's my vote for best error handling option:
Use HTTP Status Codes for problems specifically related to HTTP, and not specifically related to your web service.
When an error occurs, always return an XML document detailing the error.
Make sure the XML error document contains both an error code, and a human readable error message. For example:
1001
Invalid Google API key supplied
By following these three simple practices, you can make it significantly easier for others to interface with your service, and react when things go wrong. New developers can easily see valid and invalid requests via a simple web browser, and programs can easily (and more robustly) extract error codes and act appropriately.
The Amazon.com web services API follows the approach of returned XML document can specify an ErrorMsg element.
XooMLe also follows this approach. (XooMLe provides a RESTful API wrapper to the existing SOAP based Google API).
Another approach is by DAS ( Distributed Annotation System) which always returns 200 if there was no HTTP-error and has error information in the HTTP-header, which is less favorable, because it is not human readable, as a browser does not display the HTTP-header.
We all are know some time we will get 500 error while trying to hit wcf url. for example if pass string value to integer parameter it will throw 500 error as request error. my question is how to log, this kind error in some file? because this will not reach our actual end point class coding right? so how to log this error in some file?
Any Help?
Assuming you want to log these on the server size, you should configure WCF tracing and use SvcTraceViewer to analyze the logs. More details on MSDN: http://msdn.microsoft.com/en-us/library/ms732023.aspx.
I may very well be wrong here - but if the client is supplying the wrong parameters to a web method, that would be a 404 as no method matches the incoming request?
I would say it's the clients job to send the right data to the right function, and to handle failures appropriately (an EndPointNotFoundException perhaps)
I'm designing an API to be as HTTP compliant as I can. This includes sending specific response codes back and using the Accept header to specify versions and response types.
I understand this may appear subjective, but I'm sure there's a conventional way of doing this. I have a set of response types that the API supports, along with a vendor-specific mime type to specify the type and version.
Currently, when the client specifies a non-existant version or type, I'm just returning a 400 Bad Request with an empty body, however, I want to return a useful error message. In the event that I don't know the response type, I feel a bit dirty responding with plain text (or defaulting to JSON). Is there a header I'm missing, or some convention that I should follow? I want to get this one right from the offset.
Thanks, and my best,
Jamie
Try the status code of 406 Not Acceptable.
http://support.microsoft.com/kb/943891/
This is a list of HTTP sub-codes supported by Microsoft IIS. I've found this page damn handy since it gives you some insight into the messages they use to handle various errors. There are some HTTP sub-codes that refer to headers.