Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I would like to have a URI like this /car/toyota, however I don't want the car resource to map to a database table for example. Instead I would like car to just be resource that is used for information retrieval only (ie. no POST, PUT, or DELETE on it), and /car/toyota/ would retrieve that data somewhere else, say through another REST API on another web server that provides this information.
Is this good design?
This probably belongs on something more like https://softwareengineering.stackexchange.com/
That said, this question depends entirely on the infrastructure of the environment you're making your REST requests on. If you have the ability to control the REST API on the web server providing the information, there's really no reason to wrap that API in another API. All of the call forwarding and potential necessity to translate from one request format to another really just adds un-necessary overhead.
That said, if you're accessing an API that you have no ability to re-format, or if you're accessing an API that you don't want client servers talking to directly, then there's a potential design perk for wrapping a different REST API in your own read only API.
Unfortunately, without having a clear picture of the entire architecture and the problem you're trying to solve, it's pretty difficult to decide if a wrapped API is a good design or not. My only advice is the preferred approach would be to edit the existing API if you can, but that isn't always practical.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
As the title suggests, I'm building a simple chat app in Node/Express + React, and I'm using socket.io to get real time updates.
However, other than the chatting itself, rest of my app is very basic (registering, signing in, creating rooms etc), and while it's definitely doable to make all those requests just socket emits, it feels like bit of an overkill.
So I was thinking of creating a regular REST API for that stuff and outsourcing it into a separate file, then creating another file just for the chatting function itself, where I'd use socket.io, but I'm afraid that it may seem a bit unprofessional, or leave an impression that I don't know how to use sockets well enough.
Key point: When finished, this app will be posted to my portfolio, so I'm not very concerned about what just "can work", but rather what's the best and cleanest way to do it? Should I switch everything to sockets and use them even for basic fetching of lists and stuff? Or is it better practice to mix the two, and use REST for, well, the rest?
In my experience, To mix the two is the best way to do that.
I did that in many projects and it worked well.
I surely think that modularity is the best way to make code clean and qualified.
So, to use both of regular REST API and websocket is more professional.
Thank you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I would like to make an action where people can ask the geology at a/their location.
This would make use of GET requests from web services which are made available through the OneGeology Geoportal (http://portal.onegeology.org/OnegeologyGlobal/)
GET requests look like:
http://portal.onegeology.org/OnegeologyGlobal/proxyxml?url=https%3A//gs-seamless.geoscience.nsw.gov.au/geoserver/onegeology/ows%3FSERVICE%3DWMS%26SERVICE%3DWMS%26VERSION%3D1.3.0%26REQUEST%3DGetFeatureInfo%26FORMAT%3Dimage%252Fpng%26TRANSPARENT%3Dtrue%26QUERY_LAYERS%3Dau_nsw_25k_geounits%26LAYERS%3Dau_nsw_25k_geounits%26INFO_FORMAT%3Dtext%252Fhtml%26I%3D50%26J%3D50%26CRS%3DEPSG%253A4326%26STYLES%3D%26WIDTH%3D101%26HEIGHT%3D101%26BBOX%3D-33.689918518066406%252C150.75199127197266%252C-33.620567321777344%252C150.82134246826172&_=1587457888900
Output is
https://gs-seamless.geoscience.nsw.gov.au/geoserver/onegeology/ows?SERVICE=WMS&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&FORMAT=image%2Fpng&TRANSPARENT=true&QUERY_LAYERS=au_nsw_25k_geounits&LAYERS=au_nsw_25k_geounits&INFO_FORMAT=text%2Fhtml&I=50&J=50&CRS=EPSG%3A4326&STYLES=&WIDTH=101&HEIGHT=101&BBOX=-33.689918518066406%2C150.75199127197266%2C-33.620567321777344%2C150.82134246826172
Geoserver GetFeatureInfo output
So would want GA to respond with the "unit_name" attribute = "Londonderry Clay" .
Could someone point me in the right direction to develop such a service?
Would it be simplier if I made a mobile app version of the portal first? Or do I need to make a custom action via Dialogflow from stratch? or a 3rd way?
Well, what would be easier is to work with technologies that you're already familiar with.
Are you familiar with mobile programming? Go that route, although it will be more difficult to integrate voice for other Assistant platforms later.
Understand web programming more and you're used to building back-end services? Building a fulfillment webhook that makes this call from parameters from Dialogflow might be easier.
If you want to learn how this is typically done, and not necessarily go with what's easiest for you, you'll want to go the latter route. This involves
Designing the conversation
Building this conversation in Dialogflow
The specific procedures involved to get user information including specific location
Building a webhook running on a server to process the user input, including their location, making the call to the API, and returning the response to the user
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 months ago.
Improve this question
I'm currently developing a micro service that basically provides calculation services to other micro services. It does not store data or have any resources like a sales order. It only calls other micro services and then calculates metrics and prices to return a result.
I'm kind of struggling trying to make a rest API with resources names that are nouns when all I do is calculate stuff and return results (more like an action).
So can we have a micro services that behaves more like an HTTP API than a Restful service (is it a bad practice, an anti pattern , an architecture smell, ....)
Regards
You can use whatever you want and in your particular case I am pretty sure you won't see any drawbacks. From my point of view only difference with rest is mostly semantic -some people may also argue about cacheability but I don't think so-
Apart from rest/rpc creating microservices without any actual domain could cause a maintenance issue in the long run as you totally depend on some other microservices data whenever a change required in their side you may also need change this microservice. That is why I don't recommend those kind of calculation services unless you have a valid scalability requirement.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
This question is primarily opinion-based.
But from my experience:
Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'd like to get the data of a website. I'd like to display the table in an app. Do you have an idea how I could do it? Thanks for your answers!
Usually, you'd want the maintainer of the data you need to supply some API for machine-to-machine communication (a REST JSON web service, for example).
Since you are asking how to display the table in an app:
the easiest way would be to just point an UIWebView that way and go from there.
a more native look might be acomplished by parsing the data. As you included several 'parsing' tags, I guess this is what you'd prefer.
The problem with HTML scraping web pages (what you probably hope to do) is that the data you are looking for and foremost it's structure is prune to changes. If some unexpected changes can easily break your parser.
Thus, if you go for doing that (which might be prohibited by your school or other publisher, especially in germany), try to parse the data on your server and offer an web service for your app yourself. This way, you can react to changes of the structure faster and do not break the app for your users.
Seriously consider asking the school for an API.