I am attempting to implement the smart HTTP transport protocol in an Asp.Net MVC application. Ultimately, my goal is to enforce permissions at a branch level rather than for the whole repository. To this point, I have implemented a parser for the receive-pack and upload-pack headers but I am stuck when it comes to handling the thin packfile that makes up the rest of the request.
From hunting through the libgit2 source it appears the contents of this thin pack file are intended to just be appended to the object database. The bindings for this functionality appear to be currently implemented in libgit2sharp but are encapsulated away from the public api.
Does libgit2sharp provide any public apis for the packbuilder or for the smart transport protocol directly? If not, is there a better way to accomplish this with the libgit2sharp library?
There is an oldish PR which exposes the pack indexer to C# but I never got around to finishing it. As is so often the case in software, the pack builder isn't in libgit2sharp because nobody's cared enough yet to implement it in the mainline repository.
There is no direct access to the on-the-wire protocol parsing, and exposing it would be more work than reimplementing the parser in a nicer language (which I have done previously). There is no server component in libgit2, so it wouldn't do any of the work for you in any case.
Related
I have two software components: My application and a library (which is owned by my company, but another team), which is used by the application. The library is a client library for some service and performs HTTP requests. The library also maps the HTTP response to the internal representation of the application. This is done by injecting a mapping class into the library by the application.
I already have unit tests for the mapping class and for the application, whereas the client library call is always mocked.
Now I'm thinking of integration test the library and I'm not sure what's the best way to do that:
Mock the library call and only check that it's called with the correct parameters
Pro: If the internals of the library change (with a non-breaking change) I don't have to adapt my tests.
Con: The mapping class isn't integration tested. I can't be sure that the library is correctly configured or that the parameters the mapper gets from the library are what I expect them to be.
Mock only the HTTP call done by the library
Pro: The mapping class and the configuration of the library (if I configured it correctly) are tested.
Con: I need to figure out the internals of the library and check how the HTTP call of each test case will look like. Also if the library upgrades to a new version of the service, I would need to adapt all the HTTP mocks as well and actually shouldn't care about how the library internally works.
Replace the HTTP call in the library with an in-memory fake (=dummy) implementation during testing
Pro: Everything is tested + the tests are resilient against library changes.
Con: It's an effort to implement and maintain a fake implementation. Depending on the service, this could mean rebuilding the functionalities of the service in the library. Who should be responsible (implementation + maintenance) for the fake strategy? My team or the team that owns the library?
I'm in favor of the last point, but given that the internals of our library rarely changes, I'm not sure if a fake strategy is worth the effort.
What's your opinion on this? Can you think of another solution?
I would create helpers inside the library that would allow you to mock the HTTP response. Therefore, you'd see the code running inside the library and you could use the libraries that verify the JSON format to make sure that the http request/response is the one you're expecting.
In this sense, you're checking i) the library actually works with your system; ii) the processes the correct HTTP response; thus, your helper could be easy enough so that developers would only need to provide the content of the http response
This is my understanding:
Swagger is a notation/rules to write documentation. But why is it called a framework (like Angular/MVC)?
Swashbuckle is a program (JavaScript?) that generates the documentation (based on Swagger rules).
Swagger UI displays the documentation. It uses Swashbuckle to do this.
Is this information correct? If not can someone explain in simple terms what Swagger, Swashbuckle, and Swashbuckle UI mean?
Also, what do I lose as an API developer if I do not use this?
Swagger is a notation/rules to write documentation. But why is it called a framework(Like angular/MVC)?
It is probably called a "framework" because its' purpose is to offer a systematic way of notating the interface of any RESTful service under the OpenAPI Specification. This is a big deal to developers because the spec is overseen by the Open API Initiative under the reputable Linux Foundation.
Swashbuckle is a program(javascript ?) that generates the documentation(based on Swagger rules)
Swashbuckle is more of a package (or a library) that you can make use of in your .NET Web API projects. It's purpose, as you have correctly indicated, is to generate the Swagger spec for your project. Additionally, the Swagger UI is contained within Swashbuckle so if you are developing an API in .NET it's really a nice one-stop shop of a package. It is almost entirely written in C#, not JavaScript.
Swagger UI displays the documentation. It uses Swashbuckle to do this.
Yes, it does display the Swagger spec in a nice, human-friendly manner. However, Swashbuckle is not a necessary component for this. They are, aside from what I just said previously, completely mutually-exclusive.
Also what do I lose as an API developer, if I do not use this.
This is now entering into the realm of opinion but I'll try to be objective about it. I use Swashbuckle to assist in the creation of clients for my application APIs. After getting past the implementation learning curve (which wasn't much), this package has saved me quite a bit of time of writing the clients myself. Writing a web client is a trivial thing for small applications but enterprise-level applications have a tendency to keep growing and/or changing in complexity so it is nice to have the creation/updating of these clients completely automated.
In short, if you decide not to use it you must either resort on an alternative method of API client generation or write/update the clients yourself. If you are only developing the back end this may be completely pointless to you but it would certainly help whoever is responsible for creating the client apps that will consume your API services.
I hope these answers have been helpful. Cheers!
I have implemented a custom email server and web client. The server is just a REST API (similar to google's gmail API) that uses a 3rd party (sendgrid) for sending and receiving. The emails are stored in a database. The web client just talks to the REST client for sending and receiving.
The problem with this approach is it doesn't implement IMAP anywhere, which makes it impossible for standard clients (outlook, iphone, etc.) to connect to and use our email API. This limits customers to using only our client for email.
What I need is some sort of IMAP Server "facade" that will manage the connections to clients and make calls to my REST API for actually handling the requests (get email, send email, etc.).
How can an IMAP facade be implemented? Is there maybe a way to take an existing MailServer and gut it and point all it's "events" to making calls to my API?
tl:dr; write your gateway in Perl; use Net::IMAP::Server; override Net::IMAP::Server::Mailbox; and use one of the many Perl REST clients to talk to your server.
Your best bet for doing this quickly, while maintaining a reasonable amount of code security, is with Perl. You'll need two Perl modules. The first is Net::IMAP::Server, and here is the Github repository for that module. This is a standards-compliant RFC 3501 server that was purposely designed to have a configurable mail store. You will override the default Net::IMAP::Server::Mailbox implementation with your own code that talks to your custom email backend.
For your second module, choose your favorite Perl module(s) to use to speak to your REST server. Your choice depends on how much fine grained control you want to have over the construction and delivery of the REST messages.
Fortunately, here you have tons of choices. One possibility is Eixo::REST, which has a Github repository here. Eixo::REST seems to deal well with asynchronous vs. synchronous REST API calls, but it doesn't provide a lot of control over X509 key management. Depending on how googley your API is, there's also the REST::Google module. Interestingly, this family also has a REST::Google::Apps::EmailSettings module, specifically for setting Gmail-specific funkiness like labels and languages. Lastly, the REST::Consumer module seems to encapsulate a lot of https-specific things like timeout and authentication as parameters to Perl object instantiation.
If you use these existing frameworks, then about 90% of the necessary code should already be done for you.
Don't do this by hacking Dovecot or any other mail server written in C or C++. If you hack together a mail server quickly using a compiled language, your server will sooner or later experience all the joy of buffer overflows and stack smashing and everything else that the Internet does to fuck over mail servers. Get it working safely first, then optimize later.
(This is basically my comment again, but elaborated quite a bit more.)
Some IMAP servers, most notably Dovecot, are structured such that the file access is in a separate module with a defined interface. Dovecot isn't the only one, but it's by far the most popular and its backend interface is known to be appropriate, so I'd take that absent specific concerns.
There already exist non-file modules such as imapc, which proves that it can be done. When a client opens a mailbox backed by imapc, Dovecot parses IMAP commands, calls message access functions in imapc, imapc issues new IMAP commands, parses the server responses, returns C structs to Dovecot, Dovecot fashions new IMAP responses and returns them to the client.
I suggest that you take the dovecot source, look at src/lib-storage/inbox/index/imapc and the other backends in that directory, and implement one that speaks your REST API as a client.
Since you're familiar with .NET, I would suggest hacking either of the following implementations of IMAPv4 servers to your liking:
Lumisoft Mail Server - a very old project indeed (let's call it "mature", huh?). Don't be too turned off by the decade-old website and the lack of a github link - the source is provided under "other downloads".
McNNTP - also an older project and with a major focus on NNTP (as the name says) but very close to what you're trying to achieve in terms of the IMAP component. Take a look, you'll probably find this a good starting point.
I'm responsible for a project that is producing the server backend for an iOS application.
I would like to formally define the service interface for the clients to call so both the IOS, Android and server teams can practice contract-first development.
In the dark past we would have used WSDL and generated RPC-style client and server interop boilerplate from that. However this isn't the norm for IOS projects. We've also looked at Apache Thrift, but there is no code generator for Swift and the Objective-C generator seems to produce code that relies on deprecated IOS APIs.
Which brings us to REST, which works well as a way to move object state around. It seems less good for the kind of conversation that says "Hey server, do X with these parameters and return me a result." We just end up creating server-side controllers for particular actions, and those "define" the service's calling convention by being sticklers for getting the right parameters. Contract-last.
Is there a standard way to do contract-first web service development for iOS clients, or am I just going to have to treat documentation as the spec?
tl;dr: No.
I'm not aware of a 'standard' way of doing things, but many
client/server apps today do use some incarnation of a RESTful
interface. JSON is the usual format.
There are some well documented 3rd party utilities that can handle
this for you client side (like [RESTKit][1] in the case of REST), or
you can roll your own implementation based on apple's provided
NSURLSession or a networking library like [AFNetworking][2]
If needed, iOS can also handle socket-based communication. (3rd party
libs exist for this as well.)
[1]: https://github.com/RestKit/RestKit [2]:
http://nshipster.com/afnetworking-2/
I got the PayPal integration working well using plain old HTTP POST using C# & .NET 2/3.5. I also get all transaction details in the response.
So, if I want to use WSDL (SOAP), will there be any advantage? (you can assume I know how to use web services)
Also, are there any examples on a complete C# project using this method? I already looked at http://www.codeproject.com/Articles/42894/Introduction-to-PayPal-for-C-ASP-NET-developers
but that page tells very little about how to make a fully functional transaction using WSDL.
Any ideas?
Or "if it ain't broke, don't fix it"
thanks!
I really don't work from WSDL's very often because I'm primarily a PHP developer. I have worked with them in Adobe Flex, though, and I gotta say I liked what I saw.
Basically, I was able to hook the WSDL up in Flex (which you can do in other IDE's as well) and it automatically gave me access to all of the API calls in the system. I could see all of the possible requests (functions) available to the web service as well as how to build them without even referring to much documentation.
When building HTTP requests directly (NVP/XML/JSON/etc) you gotta refer to documentation quite a bit to see how to build the request, and there's typically more trial and error involved, too, until you get things working. The WSDL helps you get around that, although, in reality you'll probably still be referring quite a bit to documentation.
The WSDL/SOAP tools I've used with PHP don't work nearly as nice as Flex or Visual Studio from what I've seen, so I typically stick to custom class libraries that build my requests for me. when I'm working in other platforms that utilize WSDL's a little nicer, though, I definitely prefer it.