How a UK 3PL kept a major client by building the Mirakl to Mintsoft integration that didn’t exist. Custom many-to-many order splitting, inventory sync and marketplace fulfilment automation across multiple stores and Mintsoft accounts.
REST is good, better than RPC, SOAP... finally people can understand and use APIs easily and happily. The URL /customer/33245/order/8769 is perfect, looks like a directory path and reflect the relationship between the entities. Arguing about the best url, status code and best verb is the irrelevant part in REST. Why can't people just do whatever it works for the users while respecting the standards when they can ?!
I think you've inadvertently put your figure on the part that really matters. REST is worse than SOAP or something like Thrift for discoverability, worse for ease of use, worse for practically every criterion you could think about. The one thing it does right is being easy to explore with a web browser.
So optimize for that. Make it easy for a developer to look at your API with a web browser. This means simple URLs. It may mean a limited form of HATEOAS, in terms of providing links to the next things.
But it absolutely doesn't mean using HTTP status codes to convey important information. It doesn't mean using content negotiation for API versioning. It doesn't mean adopting every new HTTP verb, and frankly there's a lot of value in making every endpoint accessible over GET and POST. Those who insist on strict REST are missing why it succeeded.
For discoverability , it's a feature not a bug, when i want to use a REST API I can read the docs written for humans not try to find my way in a WSDL. Also a will built REST API is straightforward once you know the entities that you will be manipulating.
IMHO the only bad thing about REST is; it's natural for CRUD, but not as easy for non-CRUD apps.
If you use the wsdl for discovery, then you are doing something that's rather dangerous as there are no guarantees what that method does or that it is correct -> use documentation instead. If the call is something important (e.g. money transfer) "exploring" rather than knowing is grounds for firing someone.
> REST is worse than SOAP or something like Thrift for discoverability
How?
> worse for ease of use
How?
> worse for practically every criterion you could think about.
I can think of lots of criteria, but very few on which I can see a compelling argument for REST being inferior to SOAP except "degree of support from libraries written to support SOAP".
There's no WSDL or .thrift -equivalent for discovery, and no autogenerated client code which makes use harder. Getting up and running is slower because you have no way to validate that your messages are well-formed short of throwing them at the server and seeing what it sends back. What criteria are you seeing REST as better on?
HATEOAS provides both discovery and, when well-known content types are used, potentially much richer ready-to-use client code than the autogenerated host-language interfaces provided by SOAP and similar protocols.
HATEOAS only lets you discover something by going there, so to speak; it doesn't give you a complete index like a WSDL.
At the transport level you get much richer and more structured client code from SOAP. Automated HATEOAS clients are at this point purely theoretical, and anything you could put a content-type on and send over HATEOAS you could equally embed in a SOAP response. If the thing you wanted to embed can be expressed as XML, you can do much better.
Your browser is an "automated HATEOAS client". You can toss it any old HTML doc and it knows what to do with things described in the HTML content-type spec such as links, forms, images, scripts, etc.
> HATEOAS only lets you discover something by going there, so to speak; it doesn't give you a complete index like a WSDL.
HATEOAS doesn't inherently require that you "go" anywhere to get a hypertext document describing an API, and can be as complete as you want. But, since its really designed for web-scale decentralized interlinked APIs, no, its not primarily intended to have one document that gives you every possible linked endpoint.
> Automated HATEOAS clients are at this point purely theoretical
Googlebot is an example of an automated HATEOAS client that handles a wide array of content types. It is decidedly not purely theoretical.
Googlebot is not an automated HATEOAS client, it's solely an automated web client. Even if the web conformed to all the specifications it would still be an exceedingly atypical example of a HATEOAS API. And googlebot is nowhere near the reliability level that we would require for most use cases.
Then REST is a wrong word, one that doesn't point to a natural empirical cluster. The web is very different from all the other things that are called "REST API"s.
Most, but not all, "REST" APIs (other than the web) violate at least one element of the definition of REST, most commonly they don't actually implement HATEOAS, requiring out of band knowledge of applicable resource URIs or URI patterns and/or information about data formats not communicated by documentation of media types and hypertext relations.
But that's because REST is often used as a buzzword by people who don't know what the architectural style entails, or aspirationally to describe one goal of the design of an API, but one that may be compromised for conflicting goals.
It's not 'discovery' in the sense that you can't discover an url, change an id here and there and build an url for another product. You don't get endpoints for operations, you get operations that are valid only for that particular product and only for that particular state.
I used to work on Ubuntu since 10.04 but I saw no future with it (lots of bugs, error reports,...) I tried many other distros (Mint, CentOs, Fedora) everything was like everything .. Last summer I bought a Macbook Retina and switched to OS X, result is good hardware and software. I installed my Linux things ZSH,Git,LAMP,Node,... + proprietary stuff like MS office, Adobe apps, which is nice because you use best of both worlds + you get Mac specific apps like Alfred which really worth it.
So my point is my computer is my life I don't only code on it, I prefer a nice UI/UX while having a perfect Unix environment, I still use Vagrant for advanced stuff though. Linux distros are a mess they should collaborate and come up with a good ergonomic and CONSISTENT desktop environment rather than add a menu button and call it a new version.
On servers nothing beats Linux/BSD no argument there.
I personally don't care much about the desktop environment as long as it doesn't take up a lot of resources.
I mean all I really need is a panel at the top of my screen with a calendar/clock and couple of indicators/applets (battery, network, sound, email) and some kind of file manager, system configuration is usually easier done by just editing the conf files directly.
That said, I agree that the Desktop Environment situation in Linux is just bonkers, a lot of time and effort has been invested in a bunch of different DE's, each being used by a good chunk of the user base and new ones pop up every now and then just adding to the fragmentation.
I didn't want to call it VM.js since it sounds like a library, this project is a library (you can find it in js/vm.js) + UI which uses the library and define IO methods and callbacks. It's a webapp, briefly
> Add arithmetic shift left/right .. I'll add
> Add logical shift left/right .. I'll add
> Add exclusive OR (XOR) .. I'll add
> Pick a word size so your integer and bit ops have meaning .. I think I'll just rely on js types to keep things simple, If you see any reason not to please explain further
> How do I set the program counter from my assembly?
The only way to set PC is through branching
> Do I have registers (seems like a stack-based VM, so no)? If not, can I have more stacks?
Like you said it's a stack-based VM, so no registers.
Currently it's a single stack since it's enough. I never encountered a machine with multiple stacks, can you enlighten me about this ?
> Can you setup a dedicated block of memory to use as a framebuffer and render it to a <canvas> tag
I made this machine to be used by students to test compilers, But I think I'll add this feature in case there is any ambitious student who wants to embed a graphics library in his language :)
Having a fixed word size in a machine is important for being able to say, for example, what the largest and smallest integers are (assuming twos-complement arithmetic).
reply