I'm currently coding, as the part of a bigger project, a webmail client.
I'd just need a quick reference and/or pointer towards the right direction about POP3 messages, as I'll have to parse them.
I don't want to use available libraries for this. I just need to know if there is something I can read to understand what to expect in a message.
Thanks!
[Precision Edit:] I'm really talking about a single message's syntax, here. There are "From" fields, and "To" fields, and many other fields, like Mime-Type and stuff, and I want to know if there is a doc somewhere that specifies what is sent back on a successful RETR command.
[Addendum] One might want to look up RFC 822 in addition to RFC 1939.
The RFC is here
And here's a java tutorial on the subject.
Related
https://api.bing.microsoft.com/v7.0/spellcheck?text=mus&mkt=en-GB&mode=spell
Using the above URL and given my supplied API key within the request headers - I am getting no results back from the Bing Spell Checker API using PostMan or from Refit in C#(Xamarin Forms).
For 'mus' I'm expecting 'must', for 'tst' I'm expecting 'test' but, neither seem to work.
I've set the mode to 'spell' which should be the case however, even in 'proof' mode it doesn't return any results.
Please can somebody let me know why?
Thanks
The documentation explains:
Bing Spell Check API lets you perform contextual grammar and spell checking on a text string. While most spell-checkers rely on dictionary-based rule sets, the Bing spell-checker leverages machine learning and statistical machine translation to provide accurate and contextual corrections.
I assume that passing single words in most cases won’t provide enough information for this approach.
Try passing phrases that put your words in some reasonable context like mst have or quality tst.
For single word suggestions you can try a dictionary based service or software package.
I am new to echo sign. I want to implement echo sign using REST API. my question is how could i send a document for signature based on rest calls. is there any sample code for sending documents via rest.
There's not much documentation available but you can start from here:
https://secure.echosign.com/public/docs/restapi/v4#!/agreements/
SOAP documentation seems to be better, giving you a better understanding about the required fields, classes, etc. You can take a look at it here but you'll need to be logged in:
https://secure.echosign.com/public/docs/EchoSignDocumentService21
You can also take a look at these implementations:
https://github.com/nsbucky/echosignv3
https://github.com/nsbucky/echosign
Is it a bad practice when writing a RESTful API to use custom HTTP response codes like:
417 - Password not provided
418 - Database error
I see there is a list of standard HTTP response codes. However, from looking at Twitter's API, it appears Twitter tries to return standard HTTP response codes when available but their own error codes when they cannot align the error with a standard HTTP response (correct me if I am wrong).
What is the best practice for response codes (especially for errors) while creating a RESTful API? Any comments on the practice which Twitter chose to use?
Yes, yes it is bad practice... mostly.
One of the tenets of REST is that you work with the underlying protocols, as such HTTP has already defined a good set of response codes.
However, not every situation is catered for perfectly. Take Twitters 'arrest your calm', that response code is used when the request was valid, it simply is not being handled due to too many request being made.
I don't see another response code that quite matches that. The other two options are to either lie, and tell the user the request failed for some other response or give a generic 400 'you did something bad' (then in the body give a more detailed explanation).
I would favour using the generic X00 codes, and use headers or the body to add more detail about what actually went wrong. This at least conforms better to standards and less brittle.
Note though, it is terrible to take an existing error code, and repurpose it. 404 should always be used only for 'not found' errors. Don't start using it because the user can't make that request at this time of day.
The problems in using your own codes are:
The code you choose may get officially assigned to something completely different, and that could break your API in the future. (e.g. compare a 306 with a 301)
Intermediaries don't know what your code means, so cannot optimise anything. The internet works so well because it is a distributed system, not an end-to-end system.
There are generic responses for each category, x00, which should be used if nothing better exists.
You can send your own more specific error code in either the response body or (not as good) a response header. There should be no need to make up your own codes. If you have truly found something that would benefit the rest of the internet and no-one else has thought of until now, you can always submit an Internet Draft to the IETF (this is fairly easy to do).
I would not hold up Twitter as a shining example of good internet practice, though. :)
This is a theoretical question but any specific technical knowledge that could help will also be appreciated.
I am an IT Assistant with not much knowledge in programming (apart from EasyPattern and super-simple batch files) but have been given an opportunity to start getting into it by having been given a task to create a step in our document management system which is vaguely defined by the title of this question.
CONTEXT:
So, we have incoming faxes with short digit codes on them, these code correlate to identifying information in our database (relevantly; email addresses). In a watched folder environment we have software that upon auto-acknowledging these fax/image files being dropped into a designated incoming location (from a fax server) it initiates Microsoft Digital Imaging (MODI, runs in the background) to find these codes (using OCR, Optical Character Recognition) and places them into CSV files (one .csv file per code per fax page). Our database admin assures me that he can have the email addresses that correlate to the codes automatically placed into their correlating csv file.
GOAL:
It is from this point that I am being asked to find a way to have a universal unchanging email message ("We have received your fax") automatically sent to those email addresses. Upon a "way" being known, I am then to actually accomplish it.
QUESTION:
How to do this? As I said, a valid theoretical answer will suffice, for that will tell me how it can be done, which would in turn tell me what to learn, which would in turn tell me where to look.
WHERE I'M AT NOW:
I understand VBA to be a programming model within an 'event-driven' paradigm and that VBA programming projects are possible and supported in both Microsoft Outlook and Access. Does herein lie my answer? Can VBA used to accomplish this? (maybe auto import the email addresses from the csv file into the "To:" field of a outgoing email?) I'm hoping it'll be easier since the message can always stay the same (something along the lines of: We received your message). I'm reading two text books that introduce the reader to VBA in Access with one, and VBA in Outlook with the other.
I hope this message makes sense, this whole question might be naive, incoherent, or maybe even outright ignorant. But any patient and understanding response would be GREATLY appreciated.
You want something like this.
For posterity's sake, here is a summary of what it entails:
In Outlook, add a handler for the Application-level NewMailEx event.
Load each MailItem by its EntryID and handle it appropriately.
You would create your new email with Application.CreateItem(oMailItem), define its subject/body/recipients and then send it.
I'm developing a RESTful API. Currently I'm considering the use of resource-specific vendor MIME-types to convey semantics and meaning as well as well as serve as the "contract" between client and server.
So for example application/vnd.mycompany.person+xml would mean that the data in question is xml that represents a person.
I have a requirement to make this API "private-labeled" meaning a reseller could in turn provide the API to his customer without his customer knowing that it is my company's service. The way this would work is that my company would host the main api at a sort of generic url, i.e www.example.com/api then my company would use a CNAME to point our domain name to that url, and our resellers could do the same.
Internally all resource links would be relative from the API root, and so would respect the actual url that is being used.
HOWEVER, I don't want to have to understand/support arbitrary vendor specific MIME-types, so what should the "mycompany" part of the example MIME-type above be?
The HTTP spec says:
Use of non-registered media types is discouraged.
I used to use “custom” media types in my platform, but it caused issues with user agents (browsers, cURL, wget, etc.) not recognizing the content.
You could try to get your custom media type registered, but (A) that takes a while; (B) it’d take a real long while before user-agents would recognize the type, if ever; (C) you’ve indicated that you don’t want the company name always present anyway.
As an alternative to “custom” media types, I recommend utilizing media type parameters instead; they’re a blessed way to add supplementary information about content to media types.
Using parameters, your media type could be application/xml; mycompany-schema=person or maybe just application/xml; schema=person.
I have seen a couple of frameworks and tutorials that recommend vendor specific mime-type to "solve" issues with making your REST interface "truly RESTful" simply because it can be done and somehow that makes it kosher for a REST service.
One issue with this approach is that by its nature is a hack or cheat to "make it work" the way you want when the whole point of shifting to a hypermedia-driven REST service is to change the model of your API and service and change how you approach the problem. Sneaking a "valid" or allowed but not recommended HTTP value for the Content-Type is like telling the starving Venezuelans that rats are fish so they could eat them without sin during Lent. Is there anything wrong with eating a rat if that's all you have? Probably not. But does pretending its a fish make it a fish? Of course not. If you need an interface that's contract driven, use RPC or SOAP or even a custom vendor mime-type. But don't point to the spec and say it's Rest, because in the end your eating a rat and everyone knows it and you're only lying to yourself.
The second issue is that you are losing the actual rewards of the hypermedia-driven interface when you cut corners. Right away you have run into issues with user agents and your own server having to jump through hoops or simply give up because the mime-type was unfamiliar. All because you thought you could have it both ways when the point isn't to impress your clients with claims of a true Rest service or to lighten the load a bit by shedding the (obviously valuable for some contexts) extra weight of a contract-driven interaction, it was to change how your service actually interacted with external clients.
Finally, I'm really unclear on how a vendor specific mime-type actually enforces a contract any better than a defined endpoint? All of the sites that mention this technique seem to just be glowing with relief that this option exists and, quite frankly, a bit smug and pleased that they are using it, like they know it's technically "naughty" but it's just so easy and fixes everything. What does it fix? In your case, why wouldn't you simply have your inbound person request/content go to:
POST /myRestService/people
and if they have some other request, have that go to a different endpoint intended for that other data type? If you need a method does_something, wouldn't you either go with:
GET /myRestService/people/personID_123/does_something
or
GET /myRestService/people/does_something/personID_123
depending on the exact context?
And just so I don't sound mean on top of loony, any frustration or anger is not at all directed at you or your question, but at the "solution" of the vendor mime-type and the obsession everyone has developed for the "Roy Fielding officially-approved and stamped
as valid REST service" that apparently no one is even able to provide a working public example of, leaving only a sense of urgency to adopt it right away taking whatever shortcuts needed and we can deal with the shame and finger pointing later when we actually fix the problems the shortcuts made.