mustangserver
product-apim
mustangserver | product-apim | |
---|---|---|
1 | 1 | |
8 | 806 | |
- | 0.6% | |
1.1 | 9.8 | |
about 1 year ago | 11 days ago | |
Java | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mustangserver
-
Why would anyone want a REST API for electronic invoices?
ZUGFeRD (more info) is an e-invoice standard and has been renamed to Factur-X after the french also adopted it. I'm Jochen and I call myself "Mustangproject.org Chief ZUGFeRD Amatuer"Factur-X is an open European standard for B2G, B2B and B2C invoices embedding machine-readable XML invoices into human-readable PDF files. And yes, that's EN16931 compliant, i.e. eligible for European B2G invoices. To support that in my Java accounting application, I had created an open-source library called Mustangproject. That library evolved into a toolkit and now also has a command line application . In 2019, I also published an open-source proof of concept to test the feasibility of a Java framework called Dropwizard as a REST API server for Mustang, which was then still 1.x. Dropwizard allows you to create REST APIs in Java, so that your functionality can be accessed over the network, centrally maintainable and basically independent of the client development language. The results were promising, even transferring whole files was possible, which was necessary to extract from PDFs and merge PDFs and XML. This article is about how easy it is to write APIs in Java if you already have some functionality to publish.
product-apim
-
Why would anyone want a REST API for electronic invoices?
The paradox situation is that there is an overwhelming amount of work, not because everything is so hard, but because everything is so easy. There is still a lot to learn, and to do, our Dockerfile is a mess. API management wise I only just had a glance at WSO2, which looks really promising).
What are some alternatives?
Application-Gateway - OWASP Application Gateway is an HTTP proxy that handles Oauth2 authentication and session management
zilla - 🦎 A multi-protocol, event-native proxy. Securely interface web apps, IoT clients, & microservices to Apache Kafka® via declaratively defined, stateless APIs.
Nakadi - A distributed event bus that implements a RESTful API abstraction on top of Kafka-like queues
japicmp - Comparison of two versions of a jar archive
Membrane Service Proxy - API gateway for REST, OpenAPI, GraphQL and SOAP written in Java.
Armeria - Your go-to microservice framework for any situation, from the creator of Netty et al. You can build any type of microservice leveraging your favorite technologies, including gRPC, Thrift, Kotlin, Retrofit, Reactive Streams, Spring Boot and Dropwizard.
Kong - 🦍 The Cloud-Native API Gateway and AI Gateway.
homi-gateway - Fast Cloud Native API Gateway with APIOps Super Power.
WireMock - A tool for mocking HTTP services
ScaleCube - Microservices library - scalecube-services is a high throughput, low latency reactive microservices library built to scale. it features: API-Gateways, service-discovery, service-load-balancing, the architecture supports plug-and-play service communication modules and features. built to provide performance and low-latency real-time stream-processing