I am hearing the word map a lot of times lately and it is confusing me a bit.
I heard today again someone saying “we have to map the endpoints”, by endpoints he meant the api endpoints, there is both REST as well as graphql API’s in the project i am working on but I still don’t understand what to map something means. We have the different parts of Frontend that make different calls to the api’s, does mapping means to link frontend to the api’s in this case?
My apologies if this is not clear enough, some help understanding would definitely be much appreciated!
The Macmillan Dictionary describes the map onto phrasal verb as:
(map something onto something) to connect one thing to another thing, for example as a way of understanding its meaning or structure
Hence “to map API 1 onto another API 2” means how the implementation of API 1 is supposed to invoke API 2 in order to achieve its functionality.
The verb “to map something” also means to discover and catalog something. In case of APIs, “we have to map the endpoints” would mean making a catalog of the endpoints and the capabilities (individual APIs / methods) they provide.
Related
I am writing a REST API. However, one of the requirements is to allow the caller to determine if an action may be performed (so that, for example, a button can be enabled or disabled, etc.)
The action might not be allowed for several reasons - perhaps user permissions, but possibly because, for example, you can't delete a shared object, or you can't create an item with the same name as another item or an array of other business rules.
All the logic to determine if something can be deleted should be determined in the back end, but the front end must show this in the GUI.
I am trying to find the right pattern to use for this in REST, and am coming up a bit short. I could create a parallel API so for every entity endpoint there was an EntityPermissions endpoint, but that seems to be overkill. I could also do something like add an HTTP header that indicates that the request was only to check permisisons, not perform it, but that seems a bit dubious, and likely to mess up the http cache.
Can anyone point me to the common pattern for doing something like this? Does it have a name? Or a web page that discusses it? I'm sure everyone has their own ideas on this (like my dumb ideas) but I this seems to be a common enough requirement that I figure there must be a common pattern for it. But google didn't help much.
There's going to be multiple opinionated answers about this. I'll share mine. Might not be the best for your problem, but it's a valid solutions.
If you followed the real definition of REST, you would be building a hypermedia/HATEOAS-style webservice. Urls would not be hardcoded, they would be discovered and actions would be discovered by the existence of a link.
If an action may not be performed, you can just hide the link. If a user fetches the next resource they just see all the available actions right there.
A popular format for hypermedia API's is HAL. You might decorate the links further with more information from HTTP Link hints.
If this is the first time you heard of hypermedia API's, there might be a bit of a learning curve. The results of learning this can be very beneficial though.
I am wondering if it's possible in any way to get a list of businesses that have done a Google Virtual Tour (basically a Street View, for businesses) by querying in Google Maps API.
I was hoping that perhaps the Places Library might contain this information in a response, but no dice. This is kind of visible in an everyday map (see Hotel Boulderado) but I don't think the information is included in any kind of query I can do.
I also saw a few questions dealing with finding a Street View by a specific LatLng - I'm looking for a more general, area-based search.
Any ideas or things I missed?
I was hoping that perhaps the Places Library might contain this information in a response
Places API can provide you a "list of businesses" in an area by trying to filter it up with specific Place Types. You are, however, limited to the constants the API provides. If you're using PlacesService, you can use nearbysearch which I think is more appropriate to your case.
I also saw a few questions dealing with finding a Street View by a specific LatLng - I'm looking for a more general, area-based search.
I'm not sure what you mean by "area-based search", but Street View on a specific LatLng can be tricky since its only available on some areas. The Explore StreetView site highlights what countries currently have data (zooming in suggests that it doesn't necessarily captured the whole country; mostly are road routes, etc.)
A StackOverflow entry indicates a way to handle if StreetView is available or not.
Hopefully the answer raised some clarifications in your end.
The oEmbed specification mentions 2 different ways of finding the oEmbed content of an URL:
Knowing the API endpoint of the website and passing it, through a GET parameter, the URL you want info about, if it matches the URL pattern it declared.
Discovering the URL of the oEmbed version thanks to a <link rel="alternate" type="application/json+oembed" ... /> (or text/xml+oembed) HTML header.
The 2nd ways seems more generic, as you don't have to store and maintain a whole list of providers. Moreover, lists of providers are the sign of a centralized internet, where only a few actors exist. This approach is hardly scalable.
I can see a use for the 1st approach, though, for websites that can parse resources made available by someone else. For example, I can provide an oEmbed version of video pages from website Foo. However, for several reasons, mainly security-related, I wouldn't trust someone who says "I can parse resource X for you" unless X's author is OK with that, which brings us back to approach 2.
So my question is: what did I miss here? What's the use of the 1st method of dealing with oEmbed? For instance, why store (and maintain up-to-date) a whole list of endpoints and patterns like oohEmbed does if you have a generic way of discovering it on-the-fly and for virtually any resource on the internet?
As a very closely related question, which I think may be asked at the same time (please correct me if I'm wrong): what happens if one doesn't provide a central endpoint for oEmbed contents, but rather, say, expect a '?version=oembed' parameter on each URL, that returns the oEmbed version instead of the standard one?
If I recall correctly, supporting both mechanisms was a compromise that we figured would help drive adoption. It's much easier to persuade large web properties to add a single endpoint vs. adding markup (that's irrelevant to most clients) to every response body. It was a pragmatic choice.
Longer term we planned to leverage some of the work Eran Hammer-Lahav was doing around discovery rather than re-inventing it (poorly, again). Unfortunately, his ideas still haven't gotten much traction and the web still lacks a good, standardized way to do this sort of thing.
I was hoping to find an answer here but it looks like everyone else is as confused as we are. The advantage of using option 1 in my opinion is that it only uses 1 json request instead of a potentially expensive html request followed by the json request. You can always use option 2 as a fallback in case you can't match a pattern in your pre-baked list of oEmbed providers.
OEmbed discovery is a major security concern. WordPress for example has a whitelist of supported OEmbed providers.
Suppose that every random URL at the internet can trigger an OEmbed code. That means everyone can hack your site.
Steps:
Create a new site, add an OEmbed discovery.
Post the URL to a form at your site. Now your site perform the OEmbed on my behalf.
Exploit:
by denial-of-service (DOS): e.g. redirect the URL to a tarpit or feed it a 1GB json response.
by cross site scripting (XSS): inject random HTML to pages that other people can see.
by stealing the admin's session-cookie via XSS: now the attacker can login to your CMS to upload files, and exploit even more.
It's XSS to the max, with little to stop it. The only sane thing to do, is whitelisting proper endpoints. That's the oEmbed endpoints are explicitly listed.
If you want something scalable, you might like www.noembed.com and www.embedly.com They provide OEmbed support for various sites which don't do OEmbed themselves.
My client wants some of the functionality of Google maps namely:
- geocoding
- generating maps with points based on postal code or long.lat
- optimal trip mapping
Their issues with Google maps
- cannot control outages
- postal codes are sometimes inaccurate or not updated frequently for Canada/UK
- they have no way to correct inaccurate information
They would prefer to host the mapping application themselves, but will require postal code updates.
Can anyone suggest such a product?
thanks
"cannot control outages - postal codes are sometimes inaccurate or not updated frequently for Canada/UK - they have no way to correct inaccurate information"
Outages
hosting your own mapping is the only way to control this, but you would be very very hard pushed to beat Google Maps / Bing Maps uptime over the last 5 years. Take a look at the following:
OpenStreetMap for the road imagery data, this is open source data very good in the UK (Im not sure about canada) and you can make your own changes and submit them (or just change the data you have downloaded)
Geoserver, Mapnik or MapServer will read openstreetmapdata and create the image tiles needed to create your own maps in whatever style you wish. Depending on if you dont want all countries and all zoom levels these products can create all the tiles you will need in advance, but usually they have to be created in real time and cached. You need a BIG fast server to manage tile crunching
Openlayers or Leaflet are open source javascript mapping platforms that will display your tiles for you
Obviously this is just for road maps, aerial imagery would cost you an absolute fortune.
Post Code Data
Many people do not realize that UK postcode data for latitude and longitude is now completely free and available to download every quarter from the official source (ordinance survey) http://www.ordnancesurvey.co.uk/oswebsite/products/code-point-open/index.html.
This is the same data source Google will use and there is none better but it will always contain inaccuracies and always be a few months out of date.
Finally
Hopefully that answer the question you asked and gives you information to inform your client. Now for the question you didn't ask "Is this approach good value to my client?".
I won't presume to know your business or client, however what I described above is possible but with one to many months of work involved to get it all working together and even then it wont have any where near the performance or uptime of something like google /bing maps and only offers a small subset of their features.
I think you're looking for something like Caliper-It's a very custom, and I would expect expensive, solution. Not suggested.
http://www.caliper.com/GISMappingSoftwareDevelopment.htm
One solution could be to use two different mapping services and compare their results, this way there's a much better chance the data is accurate. You can also fix inaccurate data by creating a system which acts as a barrier between the API and your user, where data you know is inaccurate is corrected before it's displayed. Not sure exactly what you're doing though, so this might not work for you.
Is trip mapping/routing the basic functionality you want to do?
Before rushing into rolling your own, I'd suggest a good think about the consequences of doing so. The first that springs to mind is whilst the pros are that you can now control your data, the cons are that you now control your data.
So you are going to have to consider where and when you get updates and the processes you are going to have to employ to keep your maps in sync with the rest of the world. There are a lot of headaches involved in these things which is why so many people use externally hosted solutions such as Googles.
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 8 years ago.
Improve this question
I'm working on a web based application which uses a JSON over HTTP based API to communicate between the server and the client. The goal being that multiple clients can be developed with different goals (online web client, offline desktop client, or third party created) using the same online data to be shared through this web service.
Right now the communication between the client and server is sent via POST only through a system that works well. I read quite a bit of information about REST and being RESTful with HTTP using PUT, GET, POST, and DELETE. I could separate my API into these different categories, but it means more code and some changes to the API.
My question is: how important is it for a HTTP based API be RESTful? Is it a recommendation, an option, or a near necessity?
Thanks in advance.
As a die-hard RESTafarian I'd say use HTTP (the REST protocol in question) to its full extent. Why? Well, I'll show you two snippets from an email exchange I had yesterday with a good friend of mine who's seriously clever (and used to be a professor of IT, still lectures, still kicks ass wherever he goes) ;
Yesterday I passed an important
milestone for my mappodrhom
application: I can now launch
long-running background computations
into a worker pool. When they finish,
the workers POST back their results
directly into the REST resources.
Which triggers more background
processing, all controlled by a
dependency graph.
And the interesting aspect is that
this RESTful backgrounding is
actually independent from my
particular application. But I am
currently too tired to completely
grasp the consequences :-)
The consequences in question are huge (it's a REST framework with lots of little stacks and events and services and apps, all with their own discoverable URIs, all with the same unified interface), and in terms of extensibility and scalability it is simply unmatched in its simplicity. If your application is a dinky little thing that will never travel places or meet hot chicks, yeah maybe you don't need it. But then, I've said the same, and all of a sudden found myself on a train to Paris with a cute girl that is a secret spy for the Russians, and well, one thing led to another...
Here's my reply, with some of my own experiences ;
I think this sounds (pardon my French)
f***ing awesome! I'm experiencing
similar things with my own REST stuff,
where because the middle layer is so
thin and transparent, I can just
extend things the way I need them
without worrying too much about the
infra-structure. It's such a freedom,
such a kick-ass cool thing that my
brain is about explode, and a
worrisome curiosity to why more aren't
doing it?
In short, doing REST only half-way is just like not really doing it at all. You're just shifting your stuff over a different pipeline, missing out on a simplified API into a state-machine, semantics- and implementation decoupling at the core, working with the principles that built the net (and hence I'd say you've got rather proven ideas behind you), the unified interface, and having URIs as part of your modeling.
I know it's popular to say that you can pick and choose, that it's all just options. It's not. REST only makes sense by using it fully, but as to convincing you to actually stretch your brain a bit further and do something clever, I can only dare you to cut through the FUD (that it's all about RPC, only GET and POST necessary, you don't need it all, equivalent to JSON, SOAP and other ilk, etc.), and be smarter about how you make applications. Yeah, I dare you all!
Unless you are going to take advantage of hypermedia then I wouldn't bother trying to conform to the REST constraints. Hypermedia is the piece of the puzzle that makes the system greater than the sum of its parts.
You are free to pick and choose which of the REST constraints you want to respect in your architecture, just note that to be able to call the end result RESTful, the only optional constraint is "code-download".
It's an option amongst several for exposing a web application as a web service with a well-defined API. Other options include:
No API - The application has no real way to be used as a component in other distributed systems
SOAP - An XML format for defining API remote calls
JSON - A compact format for information exchange that can be built on to create a custom API format (or used to build a REST system if you wanted)
Many other forms of remote procedure calls and information exchange mediums.
REST has a nice ideal behind it, but that doesn't mean you have to provide a REST API for your application. If the gain isn't worth the extra effort, don't bother.
It is a recommendation. I am glad you did not go into how RESTful you need to go into as there is something called Hi-Rest and Lo-REST. You can get more information from googling. Some industry veterans I know do not much care about this, but I do find staying as close to html and http will help you in the long run and simplifies many things.
I would submit that it's a nice to have but not a must. In my experience adding this architecture increases the scope and complexity of the project, but it does add a degree of elegance to the whole. I would say if you've got the time and budget on the project, go for it, if not don't worry about it.
One (of the many) things to consider with service API's is the ease in which they can be consumed by your end user. REST is gaining a very strong tooling presence.
By far the largest dev group out there is the .NET dev group, and with ADO.NET for services (Astoria) consuming REST using Linq is very simple and very elegant.