We are currently designing a REST API that we want to publish in a few months. Since this is a brand new application we can choose any other programming language other than PHP. At this moment we are using the following link to have a base of best practices for APIs.
What is the most suitable Rich Internet Application Programming Language to construct a REST API? I know you can accomplish this goal with almost any PL, we are looking for one that will give us the base. And while you are at it, if you can point the second better and the reasoning that will be perfect.
Thanks SO for this great website.
EDIT 1: Other link related to this question.
Depends on what your team is comfortable with.
You really can't go wrong with Ruby on Rails or Microsoft .NET (using WCF with REST endpoints).
Ruby on Rails is good if that architecture works for your application and you only need that REST endpoint.
With .NET, you can create the REST endpoint for your WCF service but also provide other endpoints if you find you need them.
I actually don't think you could use an RIA language to build a REST API, because a REST (Web) API is an collection of resources served via an HTTP server. An RIA usually runs client-side.
So I assume you're asking what's the most suitable programming language to build a REST API which will be used by an RIA.
There are many good choices. I'm not sure what your parameters are, so I'll suggest what I would use if I needed to build a REST API.
Some good choices:
Java, using the Restlet framework. I use this all the time and I'm very happy with it.
Ruby, using the Ruby on Rails framework or the Sinatra micro-framework
Python, using a micro-framework such as Bottle, djng, itty, juno, mnml, newf, web.py, or Werkzeug. It's definitely possible to use a full-blown framework such as Django or CherryPy, but I've found them to be not particularly well suited to this use case.
Hope this helps!
If not PHP, then Ruby or Python.
Related
I am very interested in Integration Platform as a Service.
As we know, it is possible to generate an API spec from an API. Is the opposite possible?
I want to write a piece of software that automatically create some functions for calling the endpoints of an Open API. In order to achieve that, the piece of software should consume an API spec and generate the code. Theoretically, this could be possible, if the spec covers all endpoints with all parameters of the API, etc. but:
this is often not the case
specs are written differently from each other
My question is: what should my software consume in order to get reliable information about the API endpoints, parameters etc.? Is there a standard for that? Is the API spec the way to go?
Look at Github Copilot. They're able to generate pretty descent facsimiles of functions from API spec. Just a word of caution, the function might not be 100% accurate and so you'll still need to check over it.
In a properly designed webservice there are at least 4 layers, presentation, application, domain and infrastructure.
REST documentation describes only the presentation layer's outer surface: HTTP interface and operations, so it is not possible to generate a complete webservice based on the REST API documentation. If your application does not have any kind of logic, it is just a data structure and CRUD, then it is possible, but in that case you'd better to find a database which has a REST API and very good access control and problem solved mostly.
If you have some sort of standard documentation like WADL or JSON-LD with Hydra, then you can generate a REST API skeleton for the presentation. I just googled the topic a little bit, maybe this thesis can be useful for you: https://repositorio.ul.pt/bitstream/10451/35311/1/ulfc121800_tm_Telmo_Santos.pdf
I'm about to set up an AWS API Gateway via Cloudformation and wondering what is the better solution:
should I use the AWS Resources for Resource and Methods or is the better approach to import the well known OpenAPI (Swagger) file we have into the API Gateway Resource?
From my researches I found out that Using swagger has some limitations (https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html) but on the other hand its kind of the standard to create APIs.
So going full in on AWS Cloudformation might have some disadvantages I cannot see right now. Thats why I'm asking for experiences from someone who was in the same situation. Grateful for any guidance...
Merci A
Personally I find the best way to develop api gateway resources is using the Serverless Framework its super easy to use and integrates very easily with other AWS services i.e. Lambda.
Also under the hood serverless is just cloudformation templates so its very flexible.
Nowadays you can write your templates using SAM (Serverless Application Model https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) if you don't like the serverless framework.
Some of the benefits are that you write less cloudformation code and you can locally debug/test your lambdas/step functions.
Here is my two cents on the best practice among your solutions:
While developing products, swagger or apiary are great tools to document your API and quickly mock the API before implementing them. With a mock API and documentation in the hands of (say) a product manager, it becomes easy to get started with a solid plan for development. But tools like swagger can auto-mock an API specification and if you wish to import this specification only to mock an API, then this import feature is a great tool to use, otherwise it is not. Let me explain why.
By importing an API and orchestrating AWS resources directly from swagger, you bring in lots of limitations, the primary one being your development process does not include a framework such as serverless or zappa. This would force us to directly write lambda functions using AWS console or AWS cli, and make the project architecture complicated.
In writing lambda functions without a framework, if we know upfront that our functions would be orthogonal to each other and do not share much common dependencies, then great, this would work, but for any project with (say) a database, functions accessing external API, some endpoints being guarded by an authorizer and having other resources, using a framework is definitely the better option. It is easier to create layers and common code, for example a database wrapper class.
When using any framework, it is better to start with the framework boilerplate and make the implementation to match the documentation. By studying the advantages and limitations of that framework, we can decide if it fits our architecture.
Also, IMO, this method is not widely used, and finding help might be tough later on as the project becomes more complex.
hope this helps.
What is the difference between swagger-api and JAX-RS ?
Is the swagger-api only for documentation? (for example #ApiOperation)
As per the API docs, JAX-RS is the Java API for RESTful Web Services that provides portable APIs for developing, exposing and accessing Web applications designed and implemented in compliance with principles of REST architectural style.
Swagger, on the other hand, comes in picture when you have implemented your restful web services using any of the JAX-RS implementations (Jersey, RestEasy, Apache-CXF, etc as already mentioned by #Bijoy). Swagger adds form to your APIs by making them look good and presentable so that client code can be written easily, at the same time it also makes documentation a much less boring task by integrating it with code. Needless to say, also saves the extra time it takes to document if done after coding is over. In this sense, it is a bit revolutionary.
jax-rs is REST specification, and it is implemented by ones like jersey, resteasy etc, swagger is more on documenting and it has an easy interface if you want to test and make lot easier from different platform for adapt your rest functionalities
This is probably a pretty basic question, but are APIs language specific. In General, do certain languages only work with certain APIs or should any language be able to talk to any API.
Specifically, Bing Webmaster Tools API has code example in C#. Does that mean I can't access the API in Python?
Thanks in advance!
If an API is exposed via HTTP and returns a language-neutral format like JSON or XML (which most popular third-party APIs do) then there's no restriction on what programming language you can use to parse the API responses.
Some API providers may provide specific client libraries e.g,. The Facebook JavaScript SDK, but this doesn't preclude using a different language, it just means you'll get less support in doing so.
An API always relates to just one language. However, sometimes interfaces or libraries are created so that they can be accessed by other languages. For example, XML is used for specifying listings in ebay. It is uploaded via HTTP. However there are many libraries, such as for PHP and Java, that abstract that into their terms, but keep a direct correlation between their usage and the XML they send.
It depends. Many APIs are designed for use with one particular language, for example functionality provided by a PHP framework. Having said that, it does not necessarily mean that in the future another language could start using them; for example IronPython making use of the .NET Framework.
It is very common for compiled libraries to be used by multiple languages, e.g. graphics libraries.
You can also have web-service based APIs (e.g. Bing in your example) which respond to HTTP requests. These could be invoked by any language, or anything in general.
I work at an IP camera company and we currently have an outdated CGI HTTP API interface. The CGIs are implemented in C.
I would like to learn and implement a new HTTP RESTful API so that the following type of things can be performed:
http://[ipaddr]/api/video/start
http://[ipaddr]/api/video/stop
I would like to write this RESTful API from the ground up in my spare time so I can learn this new skill.
I am very experienced in embedded C programming and Web technology front end (HTML, JS, CSS, etc), however, I would like to implement the link between the front end web UX and the application code (and/or web backend).
I would like advice on the current methods of implementing HTTP APIs. I really like to learn the 'right way' to do things before I start.
I have found that all the things I have seen such as OAuth, XAuth, REST, SOAP, implementation languages is a bit overwhelming!
Is there anyone on Stack Overflow that could provide a sensible path to learn these things? I'm very adept at self-learning but could just do with a few pointers in the right direction.
I would like to write whatever I can in C ideally as that would be the easiest way to get into the application code. However, if people recommend another language I'm happy to go with that if there are clear pros.
Get yourself a copy of Richardson and Ruby's RESTful Web Services (O'Reilly). They talk about how to design and implement RESTful services using several different technologies. It's so good you almost don't need anything else except RFC-2616 (HTTP 1.1) and Roy Fielding's original dissertation on REST.
There are a lot of great libraries to build on (depending on how much you want to learn directly). In the Java world, the Apache HTTP Client library is a good foundational layer. A REST framework like RESTlet automates much of the rest for you, making it relatively simple.
First, you've got to figure out what your webserver is going to be, something which is probably going to be driven by your choice of OS. Windows or Linux? Or something else?
If you're using Windows, you'll likely be using something like ASP.NET or WCF; there's good REST support in those, and you can easily find some good documentation. This will probably require implementation in a managed language, though, so expect a bit of learning curve from that.
If you're using Linux as your webserver, you'll probably want to use Apache as your webserver software, which would imply any number of different possibilities for server software; PHP, Python, etc. You can likely easily invoke C from those languages, although there are probably easier ways to do what you want than invoking C from there. Of course, Linux as a webserver gives you additional options for server software; you could always go with node.js and Express for your REST API; there's a bit of learning involved to do it well, but for blistering speed, it's hard to beat node.js.
start and stop are not resources but actions, and do not belong in a URL.
Instead you should use PUT or PATCH to send a boolean such as stream=true or stream=false to a URL like http://[ipaddr]/video (no need for /api/ either)
The client sends the new state, and the camera reacts. Once the state has been changed (video started or stopped) it responds with a 200, with the new state in the response body, or 204 with no response body. Or if the operation is lengthy, you can respond with 202 Accepted and no response body.
The same can be used to start and stop /audio streams.
For more info, please read http://weblogs.java.net/blog/mkarg/archive/2010/02/14/what-hateoas-actually-means